You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The top-level links object MAY contain the following members:
"self" - a link for fetching the data in the response document.
Pagination links for the primary data, as described below.
I believe we aren't even using this key yet, correct? Since this is a MAY requirement, we technically don't need to do anything here, although paging is something we absolutely ought to support eventually, and the self key is nice to have and probably easy to add.
The text was updated successfully, but these errors were encountered:
self may be easy or not ... For the top-level, is it simply sufficient to return the link at which the resource was accessed? I'm not sure how easy it is to reverse-resolve the URL--especially in a canonical fashion--for any given object. We could add something like LinkTemplate on a class, which might be the way we have to go to enable reliable self links in each resource.
Oh, and I love the idea of pagination and it should be fairly simple to support the same way as we do filtering... I have yet to see how Ember Data is going to leverage paging at all though. They'd have to make promise chunks and provide some kind of API that would be used by a scrolling table component or something.
Yeah I don't know how paging is meant to work in ember data either. But one can always make a raw AJAX request against the API and use store.pushMany().
https://github.com/dgeb/json-api/blob/v1rc2/format/index.md#top-level-links-
I believe we aren't even using this key yet, correct? Since this is a MAY requirement, we technically don't need to do anything here, although paging is something we absolutely ought to support eventually, and the
self
key is nice to have and probably easy to add.The text was updated successfully, but these errors were encountered: