tolerate HATEOAS service not so HATEOAS

[zijianhuang]

I have to consume a service from a bank that has the response type = application/json rather than application/hal+json, and define http method in the link. Paypal API had actually define http method as well.

I had created a fork for introducing such changes.

[wis3guy]

@zijianhuang So their API is serving proper HAL but they are not specifying application/hal+json in the Content-Type header of their responses?

[zijianhuang]

@wis3guy, yes, unfortunately, even if I set Accept: application/hal+json in the request. While I had raised the issue and the service provider would be fixing this in near future, I have to continue to work on the sandbox with such content type in response. And the method property in the link is here to stay. I had add codes to address this issue, and will likely create a pull request after spending a few days more consuming the Web service.

[wis3guy]

@zijianhuang I understand your predicament, but i feel that it is unwise for this library -- dedicated to HAL document processing -- to deviate from the spec in this case. Note that other people are also making use of this client and that the changes in your fork would also affect them.

Both the mediatype (https://tools.ietf.org/html/draft-kelly-json-hal-08#section-3) and link definition (https://tools.ietf.org/html/draft-kelly-json-hal-08#section-5) of your API provider conflict with the spec as can bee seen in the provided links.

My suggestions to you would be to:

• resolve this with the provider
• keep using your fork until they resolve the conflicts.

I will think about adding 'customization' options that would allow deviation from the standard. No promisses whatsoever though!

[zijianhuang]

I see you closed this. However, my changes won't break any existing application code since I was careful enough to keep backward compatibility.

[wis3guy]

I closed the issue b/c i feel this library should remain pure in its conformation to the HAL spec.