REST API is a web interface that exposes data as resources, each with its own URL, which clients read or change with standard HTTP methods such as GET, POST and DELETE. REST stands for Representational State Transfer, an architectural style Roy Fielding described in his 2000 doctoral dissertation through constraints: client-server separation, stateless requests, cacheable responses, a uniform interface and layering. Servers reply with status codes such as 200, 201, 400, 401, 404, 429 and 5xx, and authentication travels with every request as an API key or OAuth token. Compared with SOAP, REST is lighter but lacks formal contracts. Payment APIs add idempotency keys for safe retries and webhooks for asynchronous outcomes, with amounts in minor units.
What is a REST API, by its constraints
Fielding defined REST through constraints rather than a specification. The client and server are separate; every request is stateless and carries everything needed to process it; responses declare whether they can be cached; the interface is uniform, so resources are identified by URLs and manipulated through representations; the system can be layered with proxies and gateways in between. A sixth constraint, code on demand, is optional.
In practice, most APIs called "RESTful" follow the spirit: resource URLs, HTTP verbs, HTTP status codes, and JSON bodies. Very few implement hypermedia links between resources, which Fielding considered essential.
How does REST API work
A request has a method, a URL, headers and an optional body. `GET /v1/customers/42` returns customer 42. `POST /v1/customers` creates one. The server answers with a status code: 200 for success, 201 for created, 400 for a bad request, 401 for missing credentials, 404 for not found, 429 when the client exceeded its rate limit, and 5xx for server faults.
Because each call is stateless, authentication travels with every request, typically as an API key or an OAuth access token in the Authorization header.
SOAP vs REST API
SOAP is a protocol with a formal XML envelope, a machine-readable WSDL contract and optional standards such as WS-Security for message-level signing. REST has no mandatory message format and relies on HTTPS for transport security. SOAP can run over transports other than HTTP; REST is tied to HTTP semantics.
The practical result: REST is lighter and easier to call from a browser or mobile app, while SOAP remains in bank cores, card processors and government systems built before 2010, where strict contracts were valued over developer convenience.
REST API for payment processing
Nearly every modern PSP exposes a REST API. A charge might be `POST /v1/payments` with `{"amount": 4999, "currency": "EUR"}`, amounts expressed in minor units, so 4999 means €49.99. Two additions make it safe for money. An idempotency key in the header lets the client retry a timed-out request without creating a second charge. Webhooks push asynchronous outcomes, such as a completed 3DS challenge or a chargeback, back to the merchant instead of forcing it to poll.
Open banking follows the same pattern: the UK and Berlin Group standards define REST endpoints for accounts, balances and payment consents, secured with OAuth 2.0 and mutual TLS.