Skip to content
This repository has been archived by the owner on Jan 21, 2020. It is now read-only.

Documentation request - How to send alternative HTTP status code for POST on a collection (NOT a 201 CREATED) #168

Open
jackdpeterson opened this issue Jun 26, 2016 · 4 comments
Milestone

Comments

@jackdpeterson
Copy link

What I really like about the ApiProblem object is that I can explicitly set the response code right there for handing off the right kind of problem e.g., a 422 for a domain-model validation problem or perhaps a 5xx if things really go south.

What seems to be missing in a regular response is to hand back an appropriate HTTP status code for the task at hand. A 201 make sense 90% of the time; however, sometimes an alternative response would make more sense. For the sake of this example, a 202 -- Accepted for processing, but not yet created is required (e.g., running a background task). How would one hand back the intended response but with the slight modification of altering the HTTP status code without short-circuiting the regular flow of adding in the HAL components and so forth?

Thanks

@jguittard
Copy link

202 indicates that the request has been accepted, not processed. So what you can do from your resource is to send back an instance of Zend\Http\Response, with a 202 code set to it.

You may want to set the body of your response object with some further information about the acceptance, as the RFC does not specify body should be empty like for 204.

@jackdpeterson
Copy link
Author

jackdpeterson commented Jun 27, 2016

Thanks for the response, while I could send back a Response object ... that would mean that on each request where I want to spend a regular response ... but with just a modified status code I would need to implement the HAL+JSON components manually (not saying that's a terrible thing, it just feels wrong). That's why I'm interested in seeing an alternative, more "Apigility way" of doing things from a documentation perspective. I know with Expressive in the works and the ZF3 changes coming down the pipeline that it would be reasonable to expect significant changes in Apigility controllers with respect to handling responses and PSR-7 compatible components.

Anyways, long story short -- I still believe that this is an open issue -- how does one send back a fully loaded HAL+JSON response back w/o manually re-inventing the wheel that other modules are doing automagically?

@jguittard
Copy link

Indeed, Apigility 2.0 and support of ZF3 and Expressive are currently being thought :-)
Another approach would be to dedicate a listener to handle the "response" and expose it in HAL+JSON.
I'll note down this interesting need of yours. Stay tuned!

@weierophinney
Copy link
Member

This repository has been closed and moved to laminas-api-tools/api-tools; a new issue has been opened at laminas-api-tools/api-tools#24.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants