Rest, GraphQL, and gRPC are the three commonly used organizational methods for exposing APIs on the Web.

Whenever I look at these nouns, I enter into a dyslexia. These colorful protocols fill our toolbox, and they also raise a conundrum: If I want my programs to be healthy and long-term, I have to understand what they are.

It's annoying because they're like screw-and-nut models, and your job is to just pick the right ones out of a bunch of parts, pair them up, and combine them into the function you want.

Very boring and very worthless. But for the sake of money, I had to learn. This article is to let you make choices quickly, without being sloppy, finish the work quickly, and drink a cup of tea is more interesting than tangled.

Rest

Rest is the most commonly used API interaction method, and SpringBoot has highly integrated it. It uses the most common HTTP protocol to complete stateless request interaction through semantic URLs.

Rest is short for Restfull and uses HTTP POST, GET, PUT, PATCH and DELETE to define operations on resources.

Although it has such operational significance, in normal use, we are used to only using its POST and GET methods, which correspond to the @GetMapping and @PostMapping annotations in Spring. There is no other reason, just because Rest seems to be very powerful, but the curve in enterprise development is relatively high, and many aggregated resources and complex operations cannot be abstracted into resources at all.

But the Rest variant also counts as Rest, and it's still the most widely used mode.

The reason for choosing Rest is because its ecology is too good. From Ruby to Java, from Golang to Rust, there are few languages ​​that don't support Rest. If you want to develop a web system, it's very easy to expose your API with just a few lines of code. Moreover, its integration with the gateway is very high, and various load balancing components can be said to be very proficient in the HTTP protocol. If you choose it, it is really very trouble-free.

However, Rest also means inefficiency. Since it is compatible with HTTP1.0, frequent short links also cause a waste of resources. Even for long links, the bloated size of HTTP makes it a little inferior in high-performance scenarios. In addition, it is stateless. If you want to pass some data accompanying the user such as JWT Token, then you have to put it in HTTP Header or Cookie, which increases the overall transmission burden.

In conclusion, Rest is a quick start, but in high performance, stateful scenarios, you have to choose something else.

gRPC

Of course gRPC is Google's work, because the data it transmits is encoded by protobuf, another Google product. When it comes to gRPC, you have to mention thrift, they are the same thing. But because of Google's halo, gRPC is more popular.

The development of gRPC is not as flexible as Rest, it requires you to define a contract, and then reference and transmit it on both the client and server sides.

With this contract, the data can be compressed. For example, our commonly used json has a lot of redundant information. If the json field is replaced by a fixed int, or passed in a fixed position, the field name does not need to take up that much space at all.

gRPC provides a variety of data transfer modes.

• A question-and-answer mode similar to Rest's HTTP;
• Client-Streaming The client sends data in a streaming way, and then ends with specific information, and then the server returns the result;
• The Server-Streaming Client requests the server, and the server continues to send data to the Client until it is notified of the end;
• Bidirectional Streaming duplex channel, that is the ordinary TCP link, all in the way of stream;

gRPC has been developed for so many years (2016), and the support for load balancing is also very good. Compared with traditional Rest, it uses HTTP2 to transmit data, which reduces the wait for a question and answer and reduces the occupancy of links.

If you are engaged in the Internet of Things, or some data collection in a weak network environment, this kind of data with high compression ratio will definitely allow you to do more with less. Of course, if your microservice system pursues higher performance, and Rest accounts for half of it, then gRPC is your best choice.

Of course, there are weaknesses. That is when debugging, the ecology is not as comprehensive as HTTP, various automation tools are lacking, and binary is usually dizzying.

GraphQL

GraphQL is also relatively young, only born in 2015, and it specifies the ability to fetch only "needed" data.

On a traditional Rest request, visit a specific URL and you'll get relatively consistent results. No matter how many useless fields are in the returned data, Rest requests will spit the request at you.

A GraphQL client can decide what data to fetch, and even how and in what format—that is, fetching only the data it needs without generating too much useless data.

Github is the master of GraphQL. These interfaces are listed in detail at https://docs.github.com/en/graphql.

The following is a typical query syntax with variables. It can be seen that this enables the requester such as Js to have similar programming capabilities.

query($number_of_repos:Int!) {
  viewer {
    name
     repositories(last: $number_of_repos) {
       nodes {
         name
       }
     }
   }
}
variables {
   "number_of_repos": 3
}
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.

Of course its weaknesses are also obvious. Compared with directly requesting an address, these query statements make the request structure more complicated and the learning curve is relatively steep.

For complex resource queries, especially resource queries with many fields and a very deep level, GraphQL is a good way.

End

The above is a brief introduction to the three main methods. At present, Rest is undoubtedly the most used, because of its simplicity; gRPC has a rapid development momentum, especially in the field of microservices, which has been widely used; GraphQL is complex, of course, it is a good tool for complex business data .

When your business is purely function-based and the traffic volume is average, there is no doubt that you can use Rest to implement it quickly and pay for it. If your business has high performance requirements and has a streamlined form of interaction, Then you can choose gRPC, which usually occurs in the early stage of the project, otherwise it is mainly based on the company's infrastructure; GraphQL is relatively advanced, it is very painful to introduce, and the cycle is long, whether to use it to organize data depends on you. determined.

But in any case, never use a cannon to hit a mosquito, rather than embroidering a needle on an elephant. That might not hit the mosquitoes, but blow itself up.

About the author: Miss Sister Taste (xjjdog), a public account that does not allow programmers to take detours. Focus on infrastructure and Linux. Ten years of architecture, tens of billions of daily traffic, discussing the high concurrency world with you, giving you a different taste.