REST Resource Modeling and HTTP Methods

REST-style APIs model resources and expose representations through predictable URLs. Prefer /users/{userId}/orders to action-heavy paths when the resource model is clear, but do not force every operation into CRUD if a domain command is more expressive.

Use HTTP methods consistently: GET retrieves, POST commonly creates or invokes a command, PUT replaces a resource representation, PATCH applies partial changes, and DELETE requests removal. Define pagination, sorting, filtering, field selection, and error formats before clients depend on them.

Cursor pagination is often better than offset pagination for large, changing datasets. An offset query such as skip=100000 may require expensive work and can produce duplicates or gaps when rows are inserted during traversal. A cursor based on a stable ordering key provides more predictable continuation.

Cursor-paginated endpoint

GET /v1/orders?limit=25&after=eyJjcmVhdGVkQXQiOi... HTTP/1.1
Accept: application/json

💡 The opaque cursor encodes or references the last stable ordering position. The server should validate it, cap the requested limit, and document how concurrent inserts affect traversal.

Key Takeaways

Use consistent resource and method semantics.
Document pagination and errors as part of the contract.
Prefer cursor pagination for large mutable collections when appropriate.

Knowledge Check

Which approach is most suitable for preventing duplicate payment creation after a client timeout and retry?

REST Resource Modeling and HTTP Methods

STAY UPDATED WITH BYTES!