REST API Architecture 101

Sharing is Caring

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:

  1. Uniform interface
  2. Client–server
  3. Stateless
  4. Cacheable
  5. Layered system
  6. 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.

Sharing is Caring

Brian is a software architect and technology leader living in Niagara Falls with 13+ years of development experience. He is passionate about automation, business process re-engineering, and building a better tomorrow.

Brian is a proud father of four: two boys, and two girls and has been happily married to Crystal for more than ten years. From time to time, Brian may post about his faith, his family, and definitely about technology.