Bug #10047

arRestApiPlugin /api namespace must return JSON in any case

Added by Jesús García Crespo about 4 years ago. Updated almost 3 years ago.

Status:VerifiedStart date:06/18/2016
Priority:MediumDue date:
Assignee:-% Done:

0%

Category:Web service API
Target version:Release 2.4.0
Google Code Legacy ID: Tested version:2.2, 2.2.1, 2.3
Sponsored:No Requires documentation:No

Description

Try:

$ curl -H "REST-API-Key: foobar" http://youripaddress/api/not-existing-resource/

The request generated by curl will cause a 404 response where the body contains a HTML document with the error details.

When we are hitting the /api namespace we should always return JSON documents, e.g.

HTTP/1.1 403 Forbidden
{
  "id":       "forbidden",
  "message":  "You do not have access for the attempted action." 
}

Or...

HTTP/1.1 404 Not found
{
  "id":       "not-found",
  "message":  "Resource not found." 
}

History

#1 Updated by Mike Cantelon over 3 years ago

  • Assignee set to Mike Cantelon

#2 Updated by Jesús García Crespo over 3 years ago

This could be perhaps solved with a Symfony filter (middleware) or a base Action class.

#3 Updated by Mike Cantelon over 3 years ago

I ended up fixing it in the QubitApiAction class (didn't see your update in time), but I could re-implement if it'd be more elegant.

#4 Updated by Mike Cantelon over 3 years ago

  • Status changed from New to Code Review
  • Assignee changed from Mike Cantelon to Jesús García Crespo

#5 Updated by Mike Cantelon over 3 years ago

  • Status changed from Code Review to In progress
  • Assignee changed from Jesús García Crespo to Mike Cantelon

#6 Updated by Mike Cantelon over 3 years ago

  • Status changed from In progress to Code Review
  • Assignee changed from Mike Cantelon to Jesús García Crespo

#7 Updated by Mike Cantelon over 3 years ago

  • Status changed from Code Review to Feedback

I've refactored the exception handling based on your feedback... definitely more elegant, thanks! I'm still unclear why we added the setting of sf_web_debug (I commented it out in debug mode and it didn't seem to break anything).

#8 Updated by Jesús García Crespo over 3 years ago

  • Assignee changed from Jesús García Crespo to Mike Cantelon

Thanks, Mike. LGTM!

RE: sf_web_debug - I'd say let's leave it as it was, just in case! :)

#9 Updated by Mike Cantelon over 3 years ago

Thanks Jesús!

#10 Updated by Mike Cantelon over 3 years ago

  • Status changed from Feedback to QA/Review
  • Assignee changed from Mike Cantelon to Nick Wilkinson

Merged.

#11 Updated by Nick Wilkinson over 3 years ago

  • Assignee changed from Nick Wilkinson to Dan Gillean

#12 Updated by Dan Gillean about 3 years ago

  • Assignee deleted (Dan Gillean)

#13 Updated by Nick Wilkinson almost 3 years ago

  • Assignee set to Steve Breker

Hi Steve, further to the email I sent out, assigning this to you.

#14 Updated by Steve Breker almost 3 years ago

  • Status changed from QA/Review to Verified
  • Assignee changed from Steve Breker to Nick Wilkinson

QA looks good - test results are as expected.

Tests:

1) Good IO with valid slug.
curl --verbose -H "REST-API-Key: 977746dc9a202e04" http://10.10.10.10/api/informationobjects/kathleen-munn-fonds

Result: json content returned. Correct IO details contained within.

2) Request bad slug
curl --verbose -H "REST-API-Key: 977746dc9a202e04" http://10.10.10.10/api/informationobjects/kathleen-munn-fondstest

Result: json content returned. IO not found error: {"id":"not-found","message":"Information object not found"}

3) Request bad endpoint
curl --verbose -H "REST-API-Key: 977746dc9a202e04" http://10.10.10.10/api/informationobjectstest

Result: json content returned. Bad endpoint error. {"id":"not-found","message":"Endpoint not found"}

#15 Updated by Nick Wilkinson almost 3 years ago

  • Assignee deleted (Nick Wilkinson)

#16 Updated by Nick Wilkinson almost 3 years ago

  • Requires documentation set to Yes

#17 Updated by Dan Gillean almost 3 years ago

  • Requires documentation changed from Yes to No

Also available in: Atom PDF