In the last ten years or so, APIs have become a critical business resource. The API is the real power behind the digital success of many large companies.
The REST API Architecture style was proposed by Roy Fielding in 2000. The REST API Architecture style is very different than other methodologies like SOAP or gRPC.
There’s no set standard on how to design a “REST API”, but there are a set of constraints that should be followed. We aren’t even obligated to use http although I’m not sure why anyone would build an external API that didn’t at least depend on it.
REST Constraints
For an API to be RESTful there are six rules that it needs to follow. There’s no requirement to use a specific data type for return or in the request.
The rules are as follows:
- Uniform interface
- Client–server
- Stateless
- Cacheable
- Layered system
- Code on demand (mostly legacy)
The blog article What are REST API’s constraints? covers the different constraints in a lot of detail.
API Architecture Layers
The API architecture is made up of four different layers: the Interaction Layer, Integrational Layer, Application Layer, and Information Management Layer (databases).
Each layer serves a purpose, and has an important purpose.
Interaction Layer
The Interaction Layer is where services and applications interact with business applications and data. In a more modern API, this is likely our API & Service Gateway.
Integration Layer
In the Integration Layer we would have things like the enterprise service bus or enterprise application integration platform. Integration Architects and developers work in this layer to expose services from other applications.
Application Layer
The Application Layer has a fairly self explanatory name. It’s where our applications exist, it’s our business rules, our service and response.
Information Management Layer
The Information Management Layer is our data layer – it has our databases, any caches, and does retrievals from the data systems.
