This is the 9th day of my participation in Gwen Challenge. For details, see Gwen Challenge.

API style is a controversial topic, and most developers are familiar with the REST versus GraphQL debate, let alone any other style. This article introduces eight different API styles that are common.

What are the styles of apis?

According to different characteristics, it can be divided into five categories, as follows:

  • The Web API:REST 和 so-called REST
  • The query API:GraphQL
  • Publish subscribe API: includesKafka 和 WebSub
  • RPC API:SOAP 和 gRPC
  • Ordinary file transfer

Constraints, attributes

Depending on which API style you use, constraints, attributes, and key factors are generally considered, not architectural considerations.

Consider the following example of the relationship between constraints and attributes:

  • Decoupled (constrained) apis are inherently modifiable (attributes)
  • Stateless (constraint) apis are inherently reliable (attributes) and extensible (attributes)
  • Apis that implement uniform interfaces (constraints) are essentially simple (attributes)

Of course, constraints can also lead to negative attributes, such as inefficiency, which can be caused by constraints on unified interfaces. However, to choose the right API style, factors (efficiency, quality, cost) need to be considered for the project team.

To choose the desired attributes, consider the limitations of the team.

  • Business constraints: such as use cases, customer requirements, release times
  • Geographical restrictions: e.g. geographical policy restrictions
  • Skill limits: e.g. team culture, team skills
  • Complexity constraints: Include style difficulty, extensibility requirements, and algorithm complexity

In addition to the above considerations, you may find that there are common considerations such as portability, visibility, and security when building apis with specific attributes. Yes, the following factors also need to be considered:

  • performance
  • scalability
  • Ease of use
  • modifiability
  • reliability
  • discoverability
  • Easy to develop
  • The cost of

Compared with the previous factors, the following factors are less critical but must be considered:

  • maturity
  • Enterprise applicability
  • tool
  • community
  • Resources of a specific style
  • Easy to open

Tips for choosing the right API style: Consider the above factors together to determine which style to choose, but in order to do so, you need to know the eight common API styles in terms of constraints, characteristics and so on.

REST

REST (REpresentational State Transfer), first presented in Roy Thomas Fielding’s doctoral thesis in 2000, proposes a software architecture style for the World Wide Web -REST (full name: Representational State Transfer is intended to facilitate the Transfer of information between different software/programs, such as the Internet. It refers to a set of architectural constraints and principles. An application or design that satisfies these constraints and principles is REST.

Constraints: client-server, stateless, cacheable, hierarchical system, code on demand, unified interface

Features: Performance, simplicity, scalability, visibility, portability, discoverability, modifiability, reliability

REST is ideal for building durable, extensible systems. It is also a relatively flexible and mature style, and therefore suitable for content negotiation, multimedia, and top-level authentication.

So-called REST

Both called and so-called denote so-called, the difference being that the former is a noun clause and the latter is an adjective, so the design of REST mainly lies in the design of endpoints.

Constraints: client-server, stateless, cacheable, hierarchical system, code on demand, unified interface

Features: Performance, simplicity, scalability, visibility, portability, discoverability, reliability

So-called REST is preferred by most teams because it follows the HTTP protocol and provides a unified interface to all the attributes of REST. Unfortunately, the absence of this constraint means that the modifiability provided by so-called REST is poor.

GraphQL

GraphQL is an open source, API-oriented data query operation language and the corresponding runtime environment. It was still in internal development at Facebook in 2012 and wasn’t released publicly until 2015. On November 7, 2018, Facebook transferred the GraphQL project to the newly formed GraphQL Foundation.

Constraints: client-server, stateless, hierarchical system, unified interface

Features: Easy to develop, cost effective, type safe

GraphQL offers incredible tools and a great development experience that can be quickly set up and used, and is great for both back-end and front-end communication. It has not evolved as well as REST.

Apache Kafka

Kafka is an open source stream processing platform developed by the Apache Software Foundation and written in Scala and Java. The goal of the project is to provide a unified, high-throughput, low-latency platform for processing real-time data. Its persistence layer is essentially a “massive publish/subscribe message queue based on a distributed transaction logging architecture,” which makes it valuable as an enterprise-level infrastructure for handling streaming data.

Constraints: client-server, stateless, unified interface

Features: Performance, visibility, extensibility, discoverability, reliability, type safety

Kafka is a popular publish-subscribe style that is fast, reliable, and scalable. While it has all the advantages of a message-based system: it stores messages forever, it is not suitable for distribution as an open platform and requires a lot of Java functionality.

WebSub

WebSub is an open standard for distributing distributed publishing/subscriptions over the Internet. This protocol extends the Atom and RSS protocols for data subscriptions. The main purpose is to provide instant notification of updates, which will improve the situation where clients get feeds at arbitrary intervals.

Constraints: client-server, stateless, cacheable, hierarchical system, code on demand, unified interface

Features: Simplicity, extensibility, visibility, portability, discoverability, modifiability, reliability

WebSub is another publish-subscribe API style, inherited from REST, that works well even in the open world, language independent. However, performance is certainly not as good as Kafka.

SOAP

SOAP is a protocol specification for exchanging data, which is used in computer network Web services to exchange structured information. SOAP makes it easier for web servers to extract data from XML databases, save time in formatting pages, and implement data exchange in XML format between different applications according to HTTP communication protocol, making it abstract in language implementation, platform and hardware.

Constraints: client-server, hierarchical system

Features: visibility, discoverability

It may not be the most modern style, but SOAP still has its uses. It is ideal for building on top of existing enterprise infrastructure, especially for one-to-one integration. However, for long-term strategies, be sure to consider other styles.

gRPC

GRPC is an open source remote procedure call system initiated by Google. The system is based on HTTP/2 and uses Protocol Buffers as the interface description language. Other functions: Authentication Bidirectional traffic Traffic control timeout the most common application scenario is efficient interaction between multiple language services in the microservice framework.

Constraint: client-server

Features: Performance, simplicity, reliability, and security

GRPC is a basic RPC framework supported by Google, and while it has great performance, it promises to transform much of what REST or GraphQL already provides. It does not apply to Web applications, nor does it apply to message brokers.

File Transfer

File transfer refers to the transfer of computer files from one computer to another over a channel. In computer history, many file transfer protocols have been designed for different file transfer situations.

Constraint: client-server

Features: Easy to develop, low cost

Simple file transfers are easy to overlook, but they are a cheap and easy way to transfer data. Ideal for scenarios that don’t require frequent batch processing and don’t require real-time functionality.

conclusion

The constraints and characteristics of the eight common API styles have been briefly described above to get a general idea, which will be covered in more detail later.