Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
weierophinney opened this issue Dec 31, 2019 · 3 comments
Labels
Enhancement New feature or request

Comments

@weierophinney
Copy link
Contributor

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


Originally posted by @jackdpeterson at zfcampus/zf-apigility#168

@weierophinney weierophinney added the Enhancement New feature or request label Dec 31, 2019
@weierophinney
Copy link
Contributor Author

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.


Originally posted by @jguittard at zfcampus/zf-apigility#168 (comment)

@weierophinney
Copy link
Contributor Author

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?


Originally posted by @jackdpeterson at zfcampus/zf-apigility#168 (comment)

@weierophinney
Copy link
Contributor Author

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!


Originally posted by @jguittard at zfcampus/zf-apigility#168 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant