REST Architecture

• REST: Representational State Transfer.
• REST is a style of software architecture which exploits the existing technology Web protocols - HTTP: GET, POST, …
• RESTful ref to Web Services implementing such an architecture
• A term coined by Roy Fielding in 2000

Architectural Constraints

REST defines 6 architectural constraints which make any web service – a true RESTful API.

• Uniform interface
• Client–server
• Stateless
• Cacheable
• Layered system
• Code on demand (optional)

Uniform interface

Define resources: e.g. api/users for (website, mobile app, other services)

There are 4 guidelines principle:

• Resource-Based: EX: API/users.
• Manipulation of Resources Through Representations: Client get user id and then delete and modify resource based on that user id.
• Self-descriptive Messages: URI + HTTP methods + data as json
• Hypermedia as the Engine of Application State (HATEOAS): Include other links for each response, so client can discover more other resources easily.

Client–server

Client application (Mobile, Front end Angular) and server application(Back end) MUST be able to evolve separately without any dependency on each other. A client should know only resource URIs, and that’s all.

Stateless

The server will not store anything about HTTP request.

Advantages:

• Scaling by deploying multiple servers. Because no session related dependency.
• Less complex – by removing all server-side state synchronization logic.
• Easy to cache.
• Never loses track, because the client sends all necessary information with each request.

Cacheable

A well-managed caching partially or completely eliminates some client–server interactions

Layered system

An application architecture needs to be composed of multiple layers. Intermediary servers may improve system availability by enabling load-balancing and by providing shared caches.

Code on demand (optional)

return executable code to support a part of your application, e.g., clients may call your API to get a UI widget rendering code.