REST API

A REST API (Representational State Transfer Application Programming Interface) is a way for two applications to talk to each other over a network. A client (for example, an app running in a browser) and a server exchange data using HTTP — the same protocol that loads web pages. Each piece of data, called a resource, has its own address (a URI), and to act on it you use a few standard HTTP commands: GET (read), POST (create), PUT and PATCH (change), and DELETE (remove). The communication is stateless: every request carries everything the server needs, and the server does not remember previous requests. An interface is called “RESTful” only when it follows the rules of the REST style — using HTTP and JSON alone is not enough.

What is REST, and how does it differ from a REST API?

REST is a design style, described in 2000 by Roy Fielding in his doctoral thesis. It is neither a protocol nor a ready-made standard — it is a set of rules (constraints). When you follow them, you get systems that are easy to scale and evolve and that are not too tightly coupled. A REST API, in turn, is a concrete interface built in that style, most often based on HTTP. The difference is practical: many interfaces labeled “REST” actually break some of the rules (for example, they are not fully stateless, or they do not show the links between resources). Such interfaces are sometimes called “REST-like” or simply “HTTP APIs”.

What are the architectural constraints of REST?

Fielding laid out six rules. Five are mandatory; one (code on demand) is optional:

• Client–server — a split of roles. The client handles what the user sees; the server handles data and logic. As a result, both sides can evolve independently.
• Statelessness — the server does not remember a session between requests. Each request must carry all the data it needs (for example, a login token). This makes it easier to spread traffic across many servers.
• Cacheability — a response clearly states whether it can be stored and for how long (the Cache-Control and ETag headers). Caching cuts the number of requests and speeds things up.
• Uniform interface — consistent rules: how to name resources (URIs), how to act on them, self-describing messages, and HATEOAS — links that tell the client what it can do next.
• Layered system — the client need not know whether it connects directly to the server or through intermediate layers (proxies, API gateways, load balancers, caches).
• Code on demand — optionally, the server may send the client some code to run (for example, a script). Rarely used.

How does a REST API work?

It all comes down to a simple cycle: the client asks, the server answers. The client’s request contains:

• An HTTP method — says what the client wants to do (for example, read or create).
• A resource address (URI) — e.g., /api/v1/users/42; points to the object the operation targets.
• Headers — including Authorization (a login token), plus Accept and Content-Type, which set the data format (most often application/json).
• A body — for POST, PUT, or PATCH it carries the resource data, usually in JSON.

The server handles the request and sends back a response: an HTTP status code, headers, and either the resource data or an error message. The name “Representational State Transfer” refers exactly to this — transferring a representation of a resource’s state (such as a JSON document) rather than giving direct access to whatever sits on the server.

HTTP methods and idempotency

• GET — read a resource. Safe (does not change state) and idempotent.
• POST — create a new resource or trigger an operation. Not idempotent (each repeat creates another resource).
• PUT — fully replace the resource at a given address. Idempotent.
• PATCH — partially change a resource.
• DELETE — remove a resource. Idempotent.

Idempotency is a simple rule: sending the same request several times has the same effect on the server as sending it once. This matters when, after a network error, you need to safely retry a request.

HTTP status codes

• 2xx — success (200 OK, 201 Created, 204 No Content).
• 3xx — redirection.
• 4xx — client-side errors (400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 429 Too Many Requests).
• 5xx — server-side errors (500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable).

How does a REST API differ from SOAP and GraphQL?

SOAP is a protocol, not a design style. It exchanges XML messages wrapped in an envelope, usually over HTTP but independent of the transport. It comes with extensive standards (such as WS-Security and the whole WS-* family), built-in transaction support, and a strict contract describing the service (WSDL). You pay for this with greater complexity. REST is lighter, uses HTTP’s own capabilities directly, and most often relies on JSON.

GraphQL usually exposes a single endpoint where the client itself states exactly which fields it needs. This avoids two problems typical of REST: pulling too much data (over-fetching) and too little (under-fetching). REST, on the other hand, works better with HTTP-level caching and has simpler rules. The choice depends on the shape of the data, your caching needs, and the complexity of the clients.

Why does a REST API matter for security?

REST interfaces are now one of the main attack surfaces — they expose an application’s logic and data directly to the network. The OWASP API Security Top 10 lists the most common interface vulnerabilities, including:

• Broken Object Level Authorization (BOLA/IDOR) — the server does not check whether a logged-in user is allowed to access a specific object. Just changing /users/42 to /users/43 in the address can reveal someone else’s data. This is the most common and most serious API flaw.
• Broken Authentication — weak or poorly implemented login, such as incorrect token checking.
• Broken Function Level Authorization — access to administrative operations without the right privileges.
• Excessive data exposure — the response returns more fields than the client actually needs.
• Lack of limits (rate limiting) — opens the door to abuse, mass probing, and DoS attacks (flooding a service with requests).

The basic ways to protect a REST API are:

• TLS (that is, HTTPS) for all traffic — it encrypts the transmission and protects tokens from interception.
• Login and access control — API keys, Bearer tokens (often in the form of JWT), and, for access on someone’s behalf, OAuth 2.0 with a defined set of permissions (scopes) and short-lived tokens.
• Checking input data and strict access control for every single object.
• Limiting and throttling requests, plus watching for unusual patterns.

REST APIs from a monitoring and detection perspective

For a SOC and network monitoring team, REST traffic is a valuable but difficult source of data. Requests and responses are usually JSON sent over HTTPS, so their content is encrypted — visibility comes mainly from API gateway or server logs, from metadata (the SNI server name, timings, data volumes), or from decryption at a proxy. A few characteristic signals point to abuse: a sudden spike in 401/403 responses (someone trying to bypass access control), probing consecutive identifiers one after another (BOLA/IDOR enumeration), a very high number of calls from a single source (scraping or credential stuffing — mass login attempts with stolen credentials), requests to undocumented or old endpoints (so-called shadow/zombie APIs), and unusually large responses (data exfiltration). Combining application logs with network data (NetFlow/IPFIX, that is, flow metadata) helps catch these patterns even when the payload itself is not visible.

Learn more

• OWASP Top 10 — REST APIs are often assessed against OWASP Top 10 web application risks.
• IDOR vulnerability – how to detect an attack on web applications through HTTP traffic analysis — REST APIs can be exposed to IDOR when object IDs are not properly authorized.
• North-South vs East-West Traffic — REST API calls are usually north-south traffic between clients and servers.
• Application Layer Attack (L7) — REST APIs are application-layer services and can be targeted by L7 attacks.
• Cloud Security Posture Management (CSPM) — CSPM helps find cloud misconfigurations that can expose REST APIs.
• Cloud Access Security Broker (CASB) — CASB can monitor and control access to REST APIs in cloud environments.
• Identity and Access Management (IAM) — REST APIs depend on IAM for authentication and authorization decisions.
• Cross-Site Request Forgery (CSRF) — REST APIs need CSRF protection when they rely on browser-based session authentication.