[Question] Working with Katharsis dialect for included resources, sorting, and sparse fieldsets

[Hayden Demerson]

Katharsis implements the JSONAPI spec (almost entirely) but does differ on the URL structure for included resources, sorting, and sparse fieldsets. Some examples at the bottom, documentation here

I'm curious if it would be possible to get such a structure working at all with ember-jsonapi-resources, and if so what are the good, better, and best strategies for doing that. I'm also curious that if any of these strategies involve modifying ember-jsonapi-resources, if the project would be interested in supporting the Katharsis dialect.

Simple Examples

Inclusion of related resources

GET /tasks/?include[tasks]=project

Sorting

GET /tasks/?sort[tasks][name]=asc

Sparse fieldsets

GET /tasks/?fields[tasks]=name

[Bill Heaton]

@dhdemerson this library adheres strictly to http://jsonapi.org/format/ but is also an example of an add-on that just matches a server contract and includes that format as first class in it's object structure and nomenclature. The Resource prototype (or model class) is built on the same structure of the payload from the api server. So it is a client representation of that format. As far as the query params are used this library doesn't need to enforce what params are sent to a find method of the resources service object (GET request).

It would be possible to fork and refit this library to the Katharsis dialect. My thoughts are that having data library for an ember app that makes the API contract first class in it's code and service methods and [de]serialization makes using that API contact simpler to grok in the client app. That was one of my motivations in making this library specific to the JSON API spec/format.

The way I would approach adapting (forking) this library to another API format/contract would be start with the resource prototype and reorganize it to match the API format, then scrub though the helper methods/utils for the resource to be sure any setup is adjusted based on the revised structure of the Resource prototype. Then likewise with the Adapter and Serializer prototypes adjust to the nomenclature of the API format/contract and finally the Store service is simply a facade to the adapter, so retrofit that to the revised adapter method naming. The result should be a new library that makes the Katharsis dialect first class in it's structure and nomenclature.

One thing that Ember Data does great at is providing an abstraction so that various adapter/service formats can be utilized. However this library doesn't take that approach, it simply does not abstract the format it becomes the format.

“You must be shapeless, formless, like water. When you pour water in a cup, it becomes the cup. When you pour water in a bottle, it becomes the bottle. When you pour water in a teapot, it becomes the teapot. Water can drip and it can crash. Become like water my friend.” - Bruce Lee

When you fetch data in an app with ember-jsonapi-resources the data becomes the format, when you create data in an app with this library it becomes the format.