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
Copy file name to clipboardExpand all lines: azure/ConsiderationsForServiceDesign.md
+34Lines changed: 34 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -374,6 +374,40 @@ All responses should include the `x-ms-request-id` header with a unique id for t
374
374
375
375
Finally, write sample code for your service's workflow and add the code you'd want customers using to gracefully recover from errors. Is it actually graceful? Is it something you'd be comfortable asking most customers to write? We also highly encourage reaching out to customers during private preview and asking them for code they've written against your service. Their error handling might match your expectations, you might find a strong need for better documentation, or you might find important opportunities to improve the errors you're returning.
376
376
377
+
## Pagination
378
+
379
+
Operations that return a collection of resources must consider pagination.
380
+
There are hard limits to the payload size of HTTP responses, and when the size of a collection or the resources themselves
381
+
can grow arbitrarily large there is the risk of exceeding this limit if the operation does not support pagination.
382
+
Further, adding support for pagination is a breaking change so it should be supported in the initial GA of the service
383
+
if there is any possibility that it will eventually be needed.
384
+
385
+
There are two forms of pagination that MAY be supported by RESTful APIs.
386
+
Server-driven paging mitigates against denial-of-service attacks by forcibly paginating a request over multiple response payloads.
387
+
Client-driven paging enables clients to request only the number of resources that it can use at a given time.
388
+
Services should almost always support server-driven paging and may optionally support client-driven paging.
389
+
390
+
### Server-driven paging
391
+
392
+
In server-driven paging, the service includes a `nextLink` property in the response to indicate that additional elements
393
+
exist in the collection.
394
+
The value of the `nextLink` property should be an opaque absolute URL that will return the next page of results.
395
+
The absence of a `nextLink` property means that no additional pages are available.
396
+
Since `nextLink` is an opaque URL it should include any query parameters required by the service, including `api-version`.
397
+
The service should honor a request to a URL derived from `nextLink` by replacing the value for the `apl-version` query parameter
398
+
with a different but valid api version. The service may reject the request if any other element of `nextLink` was modified.
399
+
400
+
The service determines how many items to include in the response and may choose a different number for different collections and even for different pages of the same collection.
401
+
An operation may allow the client to specify a maximum number of items in a response with an optional `maxpagesize` parameter.
402
+
Operations that support `maxpagesize` should return no more than the value specified in `maxpagesize` but may return fewer.
403
+
404
+
### Client-driven paging
405
+
406
+
An operation may support `skip` and `top` query parameters to allow the client to specify an offset into the collection
407
+
and the number of results to return, respectively.
408
+
409
+
Note that when `top` specifies a value larger than the server-driven paging page size, the response will be paged accordingly.
410
+
377
411
## Getting Help: The Azure REST API Stewardship Board
378
412
The Azure REST API Stewardship board is a collection of dedicated architects that are passionate about helping Azure service teams build interfaces that are intuitive, maintainable, consistent, and most importantly, delight our customers. Because APIs affect nearly all downstream decisions, you are encouraged to reach out to the Stewardship board early in the development process. These architects will work with you to apply these guidelines and identify any hidden pitfalls in your design.
0 commit comments