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

[weierophinney]

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 https://github.com/zfcampus/zf-apigility/issues/168

[weierophinney]

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 https://github.com/zfcampus/zf-apigility/issues/168#issuecomment-228585643

[weierophinney]

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 https://github.com/zfcampus/zf-apigility/issues/168#issuecomment-228818780

[weierophinney]

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 https://github.com/zfcampus/zf-apigility/issues/168#issuecomment-228819838