I split REST into a variant for reading data and another for creating data. With this simple framework in mind, and equipped with information from the interviews I had done before, I was able to create the following compatibility matrix:Īlong the x-axis, you can see the different architectural styles. The architectural style must also be a good fit for the data and operations I’m designing. Whatever the architectural style I choose, it must be easy for users to consume from those tools. I went back to the information I had obtained during the interviews and compiled a list of all the tools that potential consumers were using regularly. I identified a simple framework to help me identify the best architectural style to use. Create a compatibility matrix: align your API with users’ existing tools Ultimately, I wanted to align the choice of API architectural style with users’ needs. However, I wanted to know more to understand why the API consumers would want to use GraphQL. So, how do you know which architectural style to use? In one of the Knowledge Base API project meetings, GraphQL was considered a good candidate because of its versatility. SOAP can use different transport protocols, such as HTTP and SMTP. SOAP (Simple Object Access Protocol): An XML-based messaging protocol that defines a set of rules for running APIs. It uses HTTP/2 for maximum performance and works with various programming languages.
GRPC: A high-performance RPC (Remote Procedure Call) that works with a binary serialization format called Protocol Buffers. It reduces over-fetching by enabling clients to define the shape of the returned data using a query language.
GraphQL: A style that allows clients to retrieve just the data they need in a structured way. Interactions using this architectural style use standard HTTP methods (e.g., GET and POST). Representational State Transfer (REST) : A stateless, client-server communication model centered around resources identified by URIs (Uniform Resource Identifiers).
Here are some of the most popular API architectural styles: The first thing to identify during the definition phase is the API architectural style, which encompasses the design principles and constraints that define the structure and behavior of an API. After finishing the strategy phase by interviewing potential API users, I’m now in the definition phase, where the goal is to document what the API will offer. To create the Postman Open Technologies Knowledge Base API, I’ve been following our team’s internal API design playbook, which covers the strategy, definition, validation, and specification of an API.
0 kommentar(er)
