When I saw this question, I actually had a feeling, because I also asked myself this question.

When I was in a company, I received a project to build a micro-service from scratch. I knew some specifications of the interface at that time.

The familiar Restful specification, for example, has been applied to this microservice project. Seeing this question again today, I have gained some new understanding and feelings.

A quick review of the differences between GET and POST requests:

Post is more secure (it is not part of the URL, cached, stored in server logs, and browser history)

Post sends more data (GET has a URL length limit)

Post can send more data types (GET can only send ASCII characters)

Post slower than get

Post is used to modify and write data, and GET is generally used for operations such as search sorting and filtering

Get requests static resources and is cached; data is not cached

Looking at the differences above, you can see that POST is more advantageous for sending large data requests, while GET is more suitable for static resources, simple queries, and so on.

When developing the interface, I will also pay attention to use GET method for simple query requests, and post can be used for other query requests such as addition, deletion, modification and complex query, but not all of them will use POST like the company of the subject.

Netizen: Cheng Mo Morgan

Morgan Cheng, a netizen, suggested that if he were her, he would follow the “industry best practices” to make the regulations:

Net Friend: Suzanne

Another friend suggested that it was to accommodate low-skilled architects and front-end programmers.

Net friend: big wide wide

I’m going to go beyond technology and discuss from an ROI perspective why if an architectural style (e.g., Restful) is so good, why isn’t it so widely used?

The first thing to be clear about is that no matter how much you like technology, whether it’s an HTTP method here, or some usage of a programming language, an architectural design approach, or even a management and communication approach like OKR.

All these are in order to meet the needs of enterprises on the market. Simply put, you’re not being paid to conform to norms, you’re being paid to do business at an acceptable cost.

In general, the form of the interface is a trivial local issue.

For the enterprise, the more important problem for the technical team to solve is to understand the business model, to form the business architecture and stable system; It is the scalability guarantee that the system will not be stuck and hang up in the face of the massive influx of users’ requirements for system availability; Is not always crazy, data loss or data conflict stability requirements, and in order to achieve these requirements to the monitoring system of all kinds of convenience.

But do worry about POST/GET and Restful. Well, there are just a few benefits Restful can clearly list (please add them in the comments section if you missed them) :

Express different business action semantics: GET/POST/PATCH/PUT/DELETE…

Express the concept of “resources”

Express many interface functions using URL path, QueryString, header, status code, etc

The above two can lead to a “unified” interface representation around which you can implement an interface maintenance tool, such as Swagger

Get resources can take advantage of caching

** But at what cost? The forced unification of government forces business concepts that are not natural resources to be forced to “resource”, resulting in more inconsistent understanding and communication difficulties.

Of course, things can always be “abstracted”, and it is often possible to abstract business concepts as “resources”.

But I don’t see any additional short – or long-term gains from doing so, other than proving that one is smart and has a decent ability to abstract, and that it’s easier to use tools like swagger.

Messing around with things like path, querySting, etc., makes it harder for cross section governance to capture key information. For example, it is very disgusting to catch a URL with variables in the path when monitoring.

Or you may see a 404 alert and have no idea what’s wrong with the service deployment. The service is normal, but the user does not exist. Or the user exists, but the user order does not exist. The problem is that the operational tools are difficult to write and the ability to respond to online problems is reduced.

Even with Swagger, you still need to write instructions and documentation to explain its business semantics. The benefits that interface tools should provide, such as “easy to understand, automatic document generation after interface changes”, are only valid if the resources represented by the interface match the background tables/views.

That is, it is only useful for low-level interface scenarios, but not for high-level interfaces. As a result, developers have to use tools like Swagger while still looking at regular documentation. Problems that can be solved with one mechanism need to be solved with two.

Cache is good, but the biggest fear is that the control is not in place to allow users to get expired data. For Cache, dynamic and static interfaces are generally distinguished.

Cache-control: no-cache, or ETag (waste of CPU), must be manually added to most dynamic interfaces. The latter typically uses CDN, which is elegantly designed for cache.

Using methods and URL paths in different forms and doing all sorts of weird concatenations on QueryString can cause a lot of headaches for the front end, as a function call has to be translated and an interface translation layer has to be created.

No problem to reduce human efficiency. If it is Web, iOS, Android three sets of front-end, you have to make three interface translation layer.

Methods other than GET and POST can be killed by improper gateway forwarding rules.

Restful methods include Method Override… So whether it is suitable or not, when landing to listen to the curse and quarrel will know.

Someone gave an example of Google S3 using Restful interfaces to illustrate the correctness of this. But we all know what S3 is. S3 is designed to access “resources.” A tool used in the right context is certainly “right”.

S3 with good things, can only explain similar Ali cloud OSS, Tencent cloud COS can also do so. But it cannot prove that e-commerce business, social business, I medical business, government-enterprise office collaboration… These businesses also lend themselves to it.

As the technical person in charge, if he comes up with a set of interface solutions (perhaps one of them is to use POST for all HTTP interfaces), the development efficiency will be improved, communication costs will be reduced, operation and error location costs will be reduced, and the cost will be reduced and efficiency will be increased for the enterprise.

Put the cost of fiddling into other areas such as business architecture design, test systems, online monitoring, disaster mitigation and so on.

In the end, the business (users satisfied, revenue increased) and the employees (pay increased as the company’s revenue increased) benefited.

I would evaluate such people as “really understand architecture, understand technology, good at using technology to solve practical problems. I don’t know where the level went.

If a technology leader only follows a book, but never validates a solution that works in his or her own environment, then the core goals of the enterprise are not achieved. He is Zhao Kuo, should roll bedding immediately leave.

As for our company, there is only one interface POST/Action for dynamic business interfaces. In the Header, the specific interface name for X-action is given to the gateway for routing. Session represents the user login identity. As well as various tokens/signatures for recommendation, anti-weight, dyeing and security purposes.

All the service request parameters are encoded by PB in the request body, and connected with the back-end gRPC system. The interface does not provide a normal Cache except for retries.

For static interfaces, CDN and multi-level Cache are used. It’s Get, it’s Get. If a dynamic interface also wants to use HTTP layer Cache, it can apply to the gateway and configure it. Whether there is a Cache and how long the Cache lasts are controlled by the gateway and endpoints themselves.

Readers can refer to it and think “are the technical specifications we are using the most cost-effective and appropriate?” according to their own business scenarios and front-end interactions.

If you were designing your company’s API specification, would you specify post requests for all interfaces? Why?

Source: zhihu.com/question/336797348