- From: Ruben Verborgh <ruben.verborgh@ugent.be>
- Date: Tue, 20 Oct 2015 20:48:20 +0200
- To: Karol SzczepaĆski <karol.szczepanski@gmail.com>
- Cc: public-hydra@w3.org
Hi Karol, > 1. What response body should be returned for http://api.example.com/an-issue/comments request? With "view" or without it? I would say: the body of http://api.example.com/an-issue/comments?page=1 with a Content-Location of http://api.example.com/an-issue/comments?page=1. > "@type": ["Collection", "CollectionView"], This would confuse two different resources (collection / page). > what defines how many items per page there is? The server, like anywhere else on the Web. > What is the order of members? Are there any other view modifiers in force, i.e. search terms, etc? For now, just paging seems sufficient for basic use cases. Additional semantics can be added later. We should verify that the proposed paging is not incompatible with it, but I don't see any problems with the view-based model. > These get quite important as we didn't decide on how the server should handle these situation, i.e. I think it's a healthy assumption that server must guarantee that the order won't change between consequtive calls to same paged view. I'm not keen to maintain that assumption for unpaged view/collection. If the server wants to provide that guarantee, it can mark the version as timestamped using RFC 7089 (Memento). > 3. While having in mind non-RDF responses (or we wouldn't like to put that information into RDF body), how are we going to express the view i.e. via headers? I was thinking to stick to general rules RFC 2616 defines when it comes to content range and range units. The same way we did before. Hydra is there for RDF-aware representations, like JSON-LD and Turtle. We don't need to make this work for non-RDF representations as far as I'm concerned; doing so would severely limit what we can do. However, I think it's not hard to argue that a "page" is always an information resource, and can thus always be represented in RDF. The data on that page might contain non-RDF resources, but you can just link to them. > 4. View approach presented discussed here is a hypermedia control within RDF body. I'd like also to take care of the api documentation equivalent. What aspects of paging would be necessary to detail in the API documentation? Best, Ruben
Received on Tuesday, 20 October 2015 18:48:53 UTC