Open michalbundyra opened 4 years ago
Currently, HAL is used as the response format only within Apigility. I'm open to allowing it on incoming requests, and would welcome a pull request that would enable it. :)
Originally posted by @weierophinney at https://github.com/zfcampus/zf-apigility/issues/114#issuecomment-119362007
I added a pull request here which should be enough to add this enhancement.
Originally posted by @Wilt at https://github.com/zfcampus/zf-apigility/issues/114#issuecomment-125665586
Hi, we are creating a Backbone project to easily manage HAL in our SPA apps.
On one of our project we need to POST/PUT/PATCH resources which embed other resources. After reading some posts on the net (mainly https://groups.google.com/forum/#!topic/hal-discuss/0-CYh0oFUUo and https://groups.google.com/forum/#!topic/hal-discuss/SLAchdbd8E0/discussion) it seems HAL does not defines how we should send the payloads.
As an exemple if we have a
User
with an embeddedAddress
we could POST it using 2 different representations.application/hal+json (is refused by Apigility)
application/json (works with Apigility)
By default the first payload seems to be refused by Apigility which returns the following error :
In my opinion the 2 payloads should be authorized because the first one uses an
application/hal+json
content type and the second one anapplication/json
content type, is this valid ?But if we use HAL representations for GET requests why forbid the same representation for POST/PUT/PATCH requests by default ?
Perhaps Apigility should be able to manage both HAL serialization and deserialization ? Would it be a good or bad idea ?
What are best practices about this ?
Thanks,
Baptiste
Originally posted by @bgaillard at https://github.com/zfcampus/zf-apigility/issues/114