Support for JSON API

[ybart]

I am currently working on a JSON API adapter for HyperResource.

It is still a work in progress, but I'm wanting to ask feedback from the community early.

For now it can successfully parse objects with attributes and embedded links. Remote link support is not supported for now and I will probably only partial support for it because I don't need it for my project.

I have based my testing on a variation of hyper_resource_test which loads a JSON API hash using my adapter implementation instead of the default HAL+JSON ones.

The code is based on the current stable release. I intend to rebase it on the development release once finished.

I am now in the process to add a new live test for JSON API and I have the following issue :

In the live HAL+JSON test, in the root request, there is a name attribute. In JSON API, this kind of attributes are in a meta object. I'm hesitant between making meta an object and exposing it or add the attributes in the root resource.

In the former case, the caller would need to use api.meta.name rather than api.name using hal. In the latter case, the syntax would be the same but it might lead to collision issues.

For now, I am just asking which one do you prefer. If you happen to have any other suggestion, feel free to comment here.

My fork (if you feel like playing with it) : https://github.com/ybart/hyperresource

[gamache]

Hello and thank you for patiently waiting as I callously ignored your comments! I apologize for the delay.

I would not add a #meta method to HyperResource. When adding new formats, all data attributes are under #attributes and all linked data are under #links. This definitely collapses the representation of many hypermedia formats, and that is a deliberate style choice.

I will leave this issue open until I clarify this in the README.

Thanks again!

-pete

[ybart]

Thanks you very much for the feedback. I'm not actively working on this subject for now since my current implementation fulfills my current needs, despite adapter being read-only and lacking support for creating, updating and deleting resources.

I understand your design decision, and I would like to how should I handle the following:

According documentation available on JSON API Website, meta is for "meta-information about a resource, such as pagination.". However, though this information is not part of the resource itself, it should probably be available somewhere for the case when the Adapater could not guess the semantic itself. In this case, what would be appropriate ?

In the meantime, I'm looking forward for your further clarifications in the README.