Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

List endpoints should return JSON-LD #7

Closed
ldodds opened this issue Apr 18, 2018 · 3 comments
Closed

List endpoints should return JSON-LD #7

ldodds opened this issue Apr 18, 2018 · 3 comments
Labels
bug Something isn't working

Comments

@ldodds
Copy link
Contributor

ldodds commented Apr 18, 2018

The list endpoints currently return a JSON structure like this:

{
 "links": {
 },
"data": [
 ]
}

They should return a doc which:

  • has a @context property
  • has properties that are defined in the relevant spec
  • follow best practices around modelling with JSON-LD

We might want to use an ItemList http://schema.org/ItemList

@ldodds ldodds added the bug Something isn't working label Apr 18, 2018
@nickevansuk
Copy link
Contributor

Just checking on this, we'd previously had consensus that using JSON API links and data properties was the way forward here. Is this still the case?

The idea with the above was to include @context in the "data" property's items as with the RPDE feed (and is consistent with the "data" property semantics in RPDE)

@ldodds
Copy link
Contributor Author

ldodds commented Apr 18, 2018

Yep, we agreed to use this style of paging, e.g. an array of responses and specific link relations to handle paging (next, previous, etc). But the goal is for all the API responses to be valid JSON-LD and for there to be a single context declared.

This is first time I've seen really looked at what we're using in terms of syntax, rather than commenting on general approach.

As another reference, Hydra defines a response as a collection, with members and a view with similar links.:

http://www.hydra-cg.com/spec/latest/core/#collections

Have previously suggested this for RPDE too: openactive/realtime-paged-data-exchange/issues/54

@nickevansuk
Copy link
Contributor

nickevansuk commented Apr 23, 2018

Makes sense. Hydra is similar and quite nice too. Though they have a "members" array for their items, which is inconsistent with the naming of the "totalItems" property. Considering "members" has a very specific meaning in our sector, I propose we opt for "items" instead. Everything else looks very similar to the JSON API approach we'd previously discussed.

Also suggest we define totalItems as an int rather than a string as they have it, and promote absolute URLs as we've done elsewhere.

So example below:

{
  "@id": "http://api.example.com/an-issue/comments",
  "@type": "Collection",
  "totalItems": 4980,
  "view": {
    "@id": "http://api.example.com/an-issue/comments?page=3",
    "@type": "PartialCollectionView",
    "first": "http://api.example.com/an-issue/comments?page=1",
    "previous": "http://api.example.com/an-issue/comments?page=2",
    "next": "http://api.example.com/an-issue/comments?page=4",
    "last": "http://api.example.com/an-issue/comments?page=498"
  },
  "item": []
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants