In addition to that, REST is a good fit for the type of data and operations that I’m designing. Almost all the mentioned tools let users read from external REST endpoints. The information from the compatibility matrix above showed me that the architectural style that best adapts to all the popular tools is REST. Some of the compatibility cells are not perfect, meaning that some add-on or third-party tool is needed for the connection to work. With this table, I can identify the compatibility between each architectural style and each tool. Along the y-axis, you can see all the tools that I compiled from the interviews with potential API users. I did it because many tools make it easy to read external data but not so much to create it. 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)
