Two major issues that affect rest

Rest is a good thing, but it is dragged down by two problems.

I have already written some introductions and opinions on rest. Not long ago, I just saw an article translated into Chinese on the Chinese version of infoq website and found some problems. So I ran the rest. the soap debate has been carefully read again. It is entertaining. The good news is that, in the past few months, the seemingly sensational or speculative rest topics have begun to disappear from the front pages of websites and magazines. Let's take a look at it and summarize it. It's actually very simple. Rest is compromised by two problems.

First, obfuscation of the essence of rest technology. Many implementation methods are called rest, but they are not good enough. This is easier to solve. For example, the infoq Chinese site published an article translated from January this year in May 2006 (not recommended ). Unfortunately, the author chose to pass the implementation of pox (plain old XML) Over HTTP to the rest and restful titles. But let's look at the author's weather query example. The most ironic thing is, if we look at the XML input and output formats and the interaction method with http post, live is like a soap-based Web Services-it is useless to wrap the input and output files in the SOAP envelope format. As for the web services, such as http://x.com/weather/WeatherQuery/2.0

This design of uniform end-point URI is even more taboo for rest. For a truly qualified rest design, take the same weather query as an example. The service call (consumption) end should be able to directly get an image

Http://x.com/weather/city/chicago

Or

Http://x.com/weather/zip/60661

For such a unique URL, the query results can be obtained without passing parameters through the input file.

What we really need is more rest-oriented teaching like Stefan tilkov (Chinese version: simple introduction to rest ). In addition, I found that the comparison between rest and RPC in Wikipedia is also very helpful, so that developers who are used to OO can quickly recognize the rest design philosophy. In another infoq article (also recommended, but not translated), the author explores the rest URI hyperlink design principles and points out that the rest APIs of major sites such as Flickr are connected, we can see examples of errors related to this principle.

A large number of plausible and self-styled rest/restful examples confuse audio and video; it is worrying that they will trigger "pox + HTTP is rest, therefore, pox + HTTP naturally has the rest advantage.

Let's look at the second biggest problem in the rest boom over the past year. This problem is tricky. The root cause is that some radicals choose to use rest single-pick soap + WS-*, and promote the concept of rest with the mutex and exclusive mentality of the two thieves. Pete Lacey is one of the pioneers. Because of soap, enterprise computing and SOA are also involved. In the consumer Web 2.0 field, the user volume is huge and the information is relatively public, so you do not need to perform very fine security control such as in the enterprise field, rest-style Web Services, in the past few years, the performance has been outstanding. In addition, it is easy to use and allows developers who want to develop mashup and other compound applications to get started quickly. These are all obvious to all. But the success of rest cannot be directly declared as a soap failure logically. In addition, the rest fans often live in the HTTP orthodox mode and think that they do not follow the rest principles and style, which is an "Abuse" of HTTP. For example, at the end of the article "let's get down to rest, the author expressed this attitude. A netizen, Alex Xu, commented:

Why is rest opposed to soap?

Isn't JSP, ASP, and PHP also an "Abuse" of HTTP? (According to the rest principle)

The telephone line was originally used for telephone calls, but later people used it to send faxes, and used a modem to access the Internet. Later, ADSL, now ADSL +. in this way, people constantly tap into potential. why does HTTP fail?

However, because of his opposition, Peter Resi almost totally denies SOAP, WSDL, UDDI, WS-*, and even XSD in this interview. The argument of excessive expansion naturally draws a lot of evidence. For example, Paul Fremantle said that as far as he knows, eBay's soap service processes 40 million of requests every day, while Yahoo Mail is basically based on soap, and the request volume is not small. Other SOA expert Steve Jones refuted Resi's complaints about parsing XSD and XML file format elasticity.

In fact, it is better to regard rest and soap + WS-* as alternative, so that developers responsible for implementing Web services can choose their own implementation methods. The principles of SOA are inherently so-business analysts and IT architects first identify the service and standardize it in the form of contracts, the service contract should be independent from any technical platform or implementation means. Next we will discuss the binding method, service interface design, and implementation methods. The same set of business logic code can be encapsulated and bound in multiple ways based on the actual situation that meets the contract. Contract, interface, code implementation, and team Division should all be loosely coupled.

As Steve Jones pointed out in many blogs that criticize rest, it is more important to work more closely with business changes to achieve business capabilities faster. This is the goal of SOA from beginning to end. There are many ways to ship a file from location a to location B. Rest is just one of soap, rest, JMS, RMI, MQ... and so on.

SOAP, WSDL, and several major WS-* standards. After years of development, vendors and tool support have been relatively mature. Although rest is relatively simple in structure, as Peter Resi gave an example in his response to this blog, developers who select rest must evaluate it, is coding expensive when the support of tools and frameworks is relatively immature? In addition, I think of a common enterprise application scenario-when there is a security privacy requirement, rest applications can easily be used with SSL/TLS. However, once the content is encrypted, many rest supporters will talk about it, including the high scalability that can directly use the existing Web Cache Mechanism, and it will no longer exist. Sometimes, when there is no need to encrypt the content, because the content must be filtered and personalized based on the user's identity and permissions, if you use rest and http get, you must also confirm that the client and server are not allowed to cache all the web infrastructure that passes through the client, so that the content is not visible to the people you should not see (different from the previous clear http post request response, the default behavior will not be cached, and many developers have taken it for granted ). In such cases, are other rest advantages (such as simplicity) still surpassing other technical means? It is a must for enterprise developers.

Some tech giants have long been occupied by lamp, PHP, Ruby, JavaScript, and python on the consumer Web 2.0 website. In addition to experimental support for groovy and grails, now, a group of rest radical believers have emerged, creating a very dramatic conflict. Even if the fire has been ignited, do you have to make good use of it-whether or not he is over-hyped or self-inflation, take the lead, use market machines to join the hype. At the same time, some theoretical architectures, development frameworks, specifications, or tools supporting rest are introduced, leveraging the opportunity, Java and C # can be expanded to the Web 2.0 field (including consumer and Enterprise Web 2.0 ). I think this is one of the main motivations behind the announcement of strong support for rest ).

Image Source: bblfish.net/blog/page1.html