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
* feat: add pagination support for container listings
Add link-based pagination model for large containers with first/last/
next/prev navigation URIs. Add pagination section to spec, extend
container representation with pagination properties, and add pagination
terms to JSON-LD context.
* chore: formatting
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
* Apply suggestions from code review
Co-authored-by: Pierre-Antoine Champin <pierre-antoine@w3.org>
* chore: implement feedback
* fix: minor restructuring
* fix: clarify pagination model description
Removed redundant sentence about server determining page boundaries and size.
---------
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
Co-authored-by: Pierre-Antoine Champin <pierre-antoine@w3.org>
Copy file name to clipboardExpand all lines: lws10-core/lws-media-type.md
+124Lines changed: 124 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -13,3 +13,127 @@ Servers MUST support content negotiation for container representations. The resp
13
13
- If a client requests `application/json`, the server MUST respond with `Content-Type: application/json`.
14
14
15
15
In all three cases, the response body is the same JSON-LD document conforming to the LWS container vocabulary. Servers are free to support additional media types (e.g., `text/turtle`) through content negotiation.
16
+
17
+
18
+
#### Pagination
19
+
20
+
Certain composite resources, like containers, may hold a large number of resources.
21
+
To allow clients to retrieve listings incrementally, servers SHOULD support
22
+
pagination for containers whose membership exceeds a server-determined threshold.
23
+
24
+
##### Pagination Model
25
+
26
+
Pagination is link-based: the server provides pagination URIs via HTTP `Link` headers [[!RFC8288]],
27
+
allowing clients to navigate the full listing without relying on numeric offsets.
28
+
29
+
When a listing is paginated, the response body contains only the current page of items. The
30
+
composite resource's `id`, `type`, and `totalItems` properties reflect the full membership, while `items`
31
+
contains only the resources on the current page.
32
+
33
+
##### Pagination Link Relations
34
+
35
+
Pagination URIs are conveyed in `Link` headers using the following standard link relations:
36
+
37
+
-**`rel="first"`**: The URI of the first page of results. MUST be present on paginated responses.
38
+
-**`rel="last"`**: The URI of the last page of results. MAY be present on paginated responses.
39
+
-**`rel="next"`**: The URI of the next page of results. MUST be present when there are subsequent
40
+
pages. MUST be omitted on the last page.
41
+
-**`rel="prev"`**: The URI of the previous page of results. MAY be present when there are preceding
42
+
pages. MUST be omitted on the first page.
43
+
44
+
All pagination URIs are opaque to the client. Clients SHOULD NOT construct or modify pagination
45
+
URIs; they SHOULD use the URIs provided by the server.
46
+
47
+
##### Requesting Pages
48
+
49
+
A client requests the composite resource's URI to obtain the first page. The response includes pagination
50
+
Link headers that the client follows to retrieve subsequent pages. Servers MAY also support
51
+
direct access to specific pages via the pagination URIs obtained during a previous scan.
52
+
53
+
When a paginated response is returned, the server MUST respond with 200 OK. The `totalItems`
54
+
property in the response body MUST reflect the total number of items across all pages, not just the
0 commit comments