In one of the online discussion forums, Roy Fielding recorded his frustration about a service that claims to be RESTful, but that service is a mere HTTP-based interface. The service was not fulfilling all the necessary REST architecture constraints. He even said that if the Engine of Application State (and hence the API) is not being driven by hypertext, then it cannot be RESTful and cannot be a REST API.

With that said, any services that need to be termed RESTful must strictly adhere to the mandatory REST architecture constraints. Those constraints are design rules that are applied to establish the distinct characteristics of the REST architectural style.

Roy, the founder of the REST style, enforces the following REST constraints as mandatory for any web service to be qualified as RESTful. These mandatory constraints are as follows:

• Client-server
• Statelessness
• Cache
• Interface/uniform contract
• Layered system
• The optional REST constraint is COD (architectures that do not use this feature can still be considered RESTful)

Each constraint is a predetermined design decision and will have positive and negative influences on the services. However, these constraints are meant to provide a better architecture that resembles the web (perhaps positive impacts balanced with negative consequences).

There may be a need for potential trade-offs when deviating from REST constraints. Ensure those trade-offs don't weaken or eliminate the mandated constraints. If so, that architecture may no longer conform to REST, or in other words, the services (architecture) are not RESTful.