search

JsonApiClient / json_api_client

Build client libraries compliant with specification defined by jsonapi.org
MIT License
362 stars 186 forks source link

Differences with JSON:API specification #179

Open freiden opened 8 years ago

freiden commented 8 years ago

Hi, Nice work on your gem the files and classes structures really ease the read of the code. I was discovering the specification of JSON:API while testing your gem and I've seen some behaviors that doesn't seem to respect it.

Thanks by advance for your answer.

chingor13 commented 8 years ago

I always have the request return a JsonApiClient::ResultSet so that I can be confident in the return type (and that I have access to the meta data of the response as well). The fact that it always returns an array-like thing is a remnant from the initial specifications where every endpoint was supposed to return an array (so you can always iterate over all the results like you can in jQuery).

The switch back to singular/multiple resource objects returned was a pretty late design change in the spec and I had already implemented and was using a pre-release version (I still maintain a 0.x branch). I decided that the consumer of the client shouldn't have to interrogate to see if you could call each or just use the resulting object and just always know that it's an array-like thing. As a consumer, if you know you get back 0 or 1 things, then you can call .first on the result set.

The last_result_set attribute is there if you are doing actions on a resource instance (like update) and you want access to the metadata. .save on resource instance behaves similarly to ActiveRecord (returns true/false) and sets errors if it failed. If you don't have access to the last_result_set, then we've lost metadata from that request.

freiden commented 8 years ago

Ok thanks for the answer. Do you plan to change the behavior on the ResulSet to match the current specification?