REST is an architectural style, not a specification. What makes an API RESTful in practice: things in the system have URLs, the HTTP method says what you want done to them, the status code says what happened, and the server keeps no per-client session between requests. Everything the server needs to handle a request arrives with that request.
A collection lives at a path — /characters — and an item within it at /characters/1. GET reads, POST creates, PUT replaces, PATCH modifies, DELETE removes. Filtering, sorting and pagination ride on the query string. Representation is negotiated with Accept and Content-Type rather than baked into the URL. The response status is the primary result: a client that reads only the body is throwing away half the answer.
That REST means JSON over HTTP. It does not — REST says nothing about JSON, and plenty of JSON-over-HTTP APIs are not RESTful at all (a single /api endpoint taking an action name in the body is RPC wearing REST's clothes). The distinguishing property is that resources are addressable and the method carries the verb.
The catalog is 39 REST APIs with 337 endpoints between them. Any of them will do for the basics; the Protocol Lab is the one built specifically around the parts of HTTP that most mock APIs skip.
All glossary terms · Testing techniques · All 39 mock REST APIs