REST, pagination and API contracts

URL naming alone does not define REST.

UnderstandStudy an examplePractise

Understand the concept

HTTP semantics support API design, while REST includes broader architectural constraints. Resource naming, methods, statuses, representations and cache behaviour belong together. Returning JSON is not itself an architectural quality guarantee.

Offset pagination can shift or duplicate results under concurrent changes. Cursor pagination needs stable ordering and an opaque validated cursor contract. Decoding a cursor does not authorise access. Bound limits, sorting and filters.

Versioning and deprecation require compatibility plans, not merely a v2 label. Keep errors and pagination metadata stable and state the consistency clients can expect between pages.

WHEN TO USE IT

Design scalable blog and project listing APIs.

COMMON PITFALL

Treating a cursor as authorisation.

01 / PRACTICE

One topic. Three levels of depth.

HTTP / illustrative example

GET /posts?limit=20 HTTP/1.1
Host: example.test

The server must bound the limit.

This page does not send requests to external servers. Messages are readable HTTP/1.1 illustrations, not HTTP/2 or HTTP/3 wire dumps. example.test is reserved for examples. Run commands and JavaScript only in your own test environment; never publish real tokens or cookies.

02 / YOUR TURN

Try it yourself first.

Does JSON output prove an API is RESTful?

Show the solution and explanation

Worked solution

Representation format ≠ architecture

No; evaluate architecture and semantics separately.

RasimAtaberkŞahin

Understand the concept

One topic. Three levels of depth.

Try it yourself first.