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
Would adopting specs for filtering JSON responses be a useful additional layer?
Having the number of items available at the API endpoint is useful but sounds potentially expensive?
Does the Activity Streams spec enable a window of the result set to be fetched in a standard way? Basically, is pagination supported?
And is pagination supported if the number of results isn't known in advance?
Filtering at the server side seems like just search? e.g. graphQL, SPARQL, or something else ... so post 1.0 at the very least. At the client side would be implementation details. So unless I'm missing something, I think the answer is "not yet".
Number of items -- yes, in LUX we tried it, and it was (indeed) expensive as you have to keep searching for all of the matches, rather than stopping when you get at least one. And it's not really necessary either -- the important distinction is 0 vs 1.
Questions from #455 by @beaudet:
Filtering at the server side seems like just search? e.g. graphQL, SPARQL, or something else ... so post 1.0 at the very least. At the client side would be implementation details. So unless I'm missing something, I think the answer is "not yet".
Number of items -- yes, in LUX we tried it, and it was (indeed) expensive as you have to keep searching for all of the matches, rather than stopping when you get at least one. And it's not really necessary either -- the important distinction is 0 vs 1.
Pagination -- yes. Docs are a bit hard to find but: https://linked.art/api/1.0/ecosystem/search/
Pagination without total count -- yes, you can just have
next
links and nototalItems
The text was updated successfully, but these errors were encountered: