Most applications and popular websites provide a REST application programming interface (API) these days. Amazon, Netflix, Twillio, and thousands of companies have a public-facing interface that has become a significant part of their business growth.

A RESTful API is a web service API that adheres to the REST architectural properties. We briefly alluded to Roy Fielding's thesis in Chapter 4, Views and URLs, which introduced the  REST architectural style. Due to its simplicity and flexibility for a variety of use cases such as mobile applications, it has become a de facto standard in the industry for programmatic interfaces.

There are six architectural constraints of a pure RESTful system, and these are, as follows:

• Client-server: Mandates that client and server must be separate and allowed to evolve independently
• Stateless: Requires REST calls to be stateless, that is, client context is not stored on the server but at the client
• Cacheable: Specifies that responses must define themselves to be cacheable or not, which can improve scalability and performance
• Layered system: Forms a hierarchy that helps manage complexity and improve scalability
• Code on demand: Allows for code or applets to be sent by servers to clients
• Uniform Interface: Is a fundamental set of constraints that decouples the architecture, such as resources and self-descriptive messages

However, most modern APIs are not purely RESTful because they break one or more of these constraints (usually the Uniform Interface). However, they might still be called REST APIs.

Practically, most adhere to a few architectural concepts, such as these:

• Resources: Any object, data or service accessible by a Uniform Resource Identifiers (URI). This can be a single object (say a User) or a collection (say Users). Usually, they refer to a noun rather than a verb.
• Request operations: Operations on resources generally done using standard HTTP operations such as GET, PUT, POST, OPTIONS, and DELETE. They follow the same rules as well, such as GET is nullipotent (has no side effects) and PUT/DELETE is idempotent (the same result no matter how many times it gets executed).
• Error codes: REST APIs use standard HTTP error codes such as 200 (success), 300 (redirection), and 400 (user error).
• Hypermedia: Responses will usually contain hyperlinks or URIs to other actions and resources for flexibility and discoverability. For instance, use hyperlinks for pagination or nested data structures.

My recommendation will make your API as easy to use as possible rather than to strictly follow the pure REST constraints. Many well-known and popular APIs violate some of them. If a REST-ish API design is cleaner than otherwise, go for it!