REST

Overview

What it means and why it exists

REST, short for Representational State Transfer, is an architectural style for designing web interfaces around resources, standardized operations and stateless requests. Many payment services use HTTP APIs influenced by REST principles.

How it works

A client sends an HTTP request to a resource endpoint, such as GET /payments/{id} or POST /payments, and receives a representation such as JSON. Authentication identifies the caller, HTTP status codes communicate broad outcomes, and resource identifiers connect related records. Requests should carry enough context for independent processing.

Technical details worth understanding

A practical payment API may be described as REST even when it uses action endpoints or imperfect resource modeling. Robust clients distinguish transport errors from business states, apply correct retry rules, paginate list responses and verify server-provided identifiers. Stateless does not mean the payment itself has no state; it means each client request is self-contained.

What can go wrong

Repeated POST requests can create multiple resources unless the API implements an idempotency mechanism. HTTP success is not proof of blockchain payment. Credentials should be transmitted over HTTPS and stored server-side with least-privilege permissions.

Practical checks

Define which methods are safe to retry and which create new resources. Validate JSON schema and interpret HTTP errors separately from business-state fields. In documentation, show example request bodies, relevant headers and idempotency behavior; a successful HTTP response from POST /payments does not mean a customer paid.

Related concepts

Payment Status API, Webhook, API Key.

Further reading

OWASP — REST Security Cheat Sheet.