Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Design a REST API around the domain resources clients need: give collections and individual items predictable noun-based paths, use HTTP methods and status codes for their standard meanings, return a stable structured error format, and apply one documented pagination contract across collections. There is no universal rule for every API’s casing or pagination style; consistency and clear client-facing behavior matter most.

How do I design REST API resources and paths?

Start with the business concepts clients work with, not database tables or operation names. A path should identify a resource; the HTTP method should express the operation. Microsoft Learn recommends basing resource URIs on nouns rather than verbs, while the Zalando RESTful API and Event Guidelines likewise favor verb-free URLs. See Microsoft Learn’s REST API design guidance and Zalando’s RESTful API and Event Guidelines.

Client intent Resource-oriented path Why it is predictable
List orders GET /orders The collection is named, and the method requests its representation.
Create an order POST /orders The collection path stays the same; the method conveys the operation.
Read one order GET /orders/{order-id} The item is addressed consistently within its collection.
Read a line item belonging to an order GET /orders/{order-id}/line-items/{line-item-id} The path shows the genuine parent-child scope.

Choose and document one path style

Zalando’s guideline recommends plural collection names, domain-specific terms, and lowercase ASCII kebab-case path segments, such as /sales-orders/{sales-order-id}. These are conventions, not a universal REST requirement. Choose the convention that fits your API, document exceptions, and apply it consistently. Prefer a meaningful domain name such as /line-items over a generic name such as /items when the domain distinction matters.

Keep identifiers stable from the client’s perspective

Use identifiers clients can treat as opaque values. Exposing an identifier’s internal or compound structure can constrain future changes, even if that structure is convenient for implementation today. Nest a resource under a parent only when it is genuinely scoped to that parent; avoid deep or arbitrary nesting that obscures which resource a client is addressing.

What’s actually slowing this PC down?

Pick the symptom - the matching free tool is one click away.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

How should REST APIs handle errors?

Return an HTTP status code that communicates the broad outcome, then use a consistent structured body to explain the application-specific problem. Zalando recommends application/problem+json for client errors (4xx) and server-side processing errors (5xx), with API-specific problem types or additional details where useful.

A practical contract distinguishes the HTTP-level result from the explanation a client can act on. For example, a validation failure should identify the relevant input or condition, while a server error should not expose stack traces or sensitive implementation details. Document endpoint-specific errors when clients need them to choose a response or recover. Zalando cautions that clients must also tolerate failures with no Problem JSON body: a gateway, other intermediary, or service unable to produce a body may have generated the response.

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Should I use cursor or offset pagination?

Paginate collections that may grow beyond a few hundred entries. Choose based on how clients navigate, collection size, backend cost, and how the data changes while a client is traversing it. Zalando’s guideline describes both approaches and their trade-offs.

Choice Best fit Trade-offs to account for
Offset: limit and offset Clients need familiar numeric positions or jumps to a numbered page, and the expected collection size and backend can handle the queries. Insertions or deletions between requests can make entries repeat or be skipped. Deep offsets can be inefficient.
Cursor: limit and cursor Clients mainly traverse forward or backward through a large or changing collection, rather than jumping to an arbitrary page. Cursors are less familiar to some clients and frameworks. If the record anchoring a cursor disappears, traversal has an edge case to handle.

Keep pagination parameters and behavior coherent

Use the same parameter names and semantics across collection endpoints: for example, limit for the requested page size, offset for an offset position, and cursor for a cursor-based position. Define how filtering interacts with pagination so a client can continue through the same logical collection rather than accidentally changing the result set between pages.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Make cursors opaque and links actionable

A cursor is a continuation token, not a public encoding clients should interpret. Zalando states: “The cursor used for pagination is an opaque pointer to a page, that must never be inspected or constructed by clients.” The token may encode a page position, direction, and filters—or a hash of filters—so the service can reproduce the intended traversal. Clients should pass it back exactly as supplied.

Expose pagination through a consistent page object or links. A page object can contain self, first, prev, next, last, and items; alternatively, provide clear next and prev links. Omit a previous or next link when no such page is available. A client should follow the service-provided link or token instead of constructing a cursor URL itself.

What should a REST API consistency checklist include?

  • Use domain resource names, a documented path convention, and a predictable collection/item pattern.
  • Let HTTP methods express operations instead of putting action verbs in resource paths.
  • Keep identifiers stable and avoid exposing internal structure unnecessarily.
  • Use appropriate HTTP status codes and a stable Problem JSON error contract; do not assume every infrastructure failure has an application error body.
  • Choose offset or cursor pagination for the collection’s navigation and scale needs, and document the trade-offs.
  • Standardize pagination parameter names, filtering behavior, response fields, and link semantics across endpoints.
  • Keep cursors opaque so clients can safely continue a traversal without coupling themselves to token internals.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.