Architectural Style for APIs — how to make a choice

So much choice, when building a new API. Which architectural style should we choose for our cool new API? Are there any best practices regarding the architectural style for APIs?

But first, what is an architectural style? In general, an architectural style is a large-scale, predefined solution structure. There are architectural styles for pretty much anything, for example for building houses, for building software and for building APIs in particular. Using an architectural style helps us to design the solution quicker than designing everything from scratch.

Architectural styles provide predefined solution elements and are thus similar to design patterns or design templates. Whereas design patterns and templates are often used to solve local implementation issues, such as iterating through a list, architectural styles provide a solution for a larger challenge. The decision for an architectural style is far-reaching and permeates the complete solution.

The choice of architectural styles should be one of the first decisions when building a new API, as this is a decision that is hard to change later.

• REST API Style (Representational State Transfer) with HATEOAS in all its “levels” as defined in the Richardson Maturity Index.
• GraphQL API Style
• RPC API Style (Remote Procedure Call)
• SOAP API Style
• gRPC API Style