In the basic technical implementation of SOA, WebService occupies a very important position. We usually mention the first idea of WebService is that soap messages interact on various transmission protocols. In recent years, the idea of rest has gradually been accepted by everyone along with SOA. At the same time, the open APIs provided to developers by major websites have aroused the upsurge of rest-style WebService.
Before receiving an email for a new requirement, I only read Fielding's restful doctoral thesis through a thorough understanding of rest. To be honest, I wanted to understand such a new concept, I just had a superficial understanding of its internal thoughts. The latest requirement of ASF is that it may need to implement rest-style WebService integration, so we have to take a good look at the true meaning of rest and the current design methods of major websites. Later I want to express some of my views and opinions of this beginner. I hope to get more feedback and opinions before I integrate rest into ASF.
SoapWhat is soap? I don't want to mention it. Google is full of eyes. In fact, soap was originally a solution for rpc. Simple Object Access Protocol is very lightweight. At the same time, it can be used as an application protocol to transmit messages (HTTP, SMTP, etc.) based on multiple transmission protocols ). However, with the wide application of soap as a WebService and the increasing addition of content, developers now think that soap is very heavy and has a high threshold for use. In the subsequent development of soap, the establishment of a series of WS-* protocols increased the maturity of soap and increased the burden on soap.
RestIn fact, rest is not a protocol or a standard, but an interpretation of the original design of the HTTP protocol. Nowadays, HTTP is widely used as a transmission protocol, rather than the application protocol that the original designer considered. A soap-type WebService is the best example. a soap message simply carries an HTTP protocol as a message, so that all parameters (such as encoding and error codes) in the HTTP protocol are ignored. In fact, the most lightweight application protocol is the HTTP protocol. The abstract get, post, put, and delete in the HTTP protocol is like the most basic addition, deletion, modification, and query in the database, the various resources on the Internet are like records in databases (which may not be a good analogy). Operations on various resources can always be abstracted into these four basic operations, after defining the resource locating rules, resource operations can be implemented through the standard HTTP protocol, and developers will also benefit from this lightweight protocol. As you can understand, there are several key points in the concept of rest: 1. resource-oriented interface design some interface design is designed for resources, which is similar to our object-oriented and process-oriented design differences, however, the operating entities on the network are viewed as resources, and the URI design also reflects the resource positioning design. There will be some web site API design said that rest design, in fact, is a mixture of RPC-REST, not the idea of rest. 2. abstract operations are based on crud. Get, put, post, and delete operations in HTTP correspond to four types of operations: read, update, create, and delete, it is enough to abstract these four types. However, for some complex business service interface designs, such abstraction may not be able to meet the requirements. In fact, this problem is also exposed in the API design of the following websites. If you want to design completely according to the rest idea, then the applicable environment will be limited, it is not universally applicable. 3. HTTP is the application protocol rather than the transmission protocol, which is clearly reflected in the API analysis of major websites. In fact, some websites have already taken the path of soap, which is the concept design of rest, it is actually a set of private soap protocols, so it is called a rest-style custom SOAP protocol. 4. stateless, self-contained is not only for rest, but also for interface design. It is also the most basic guarantee for scalability and efficiency, the same applies to WebServices that use soap.
Rest vs soap
Maturity:Although soap has evolved from its original intention to the present, the release and calling of services in heterogeneous environments, as well as vendor support have all reached a relatively mature level. Web services that interact with each other through soap on different platforms can communicate well (in some complex and special parameters and response object parsing, the Protocol is not detailed, as a result, it still needs to be partially corrected.) Rest many large foreign websites have released their own development APIs, many of which provide soap and rest Web Services, according to the survey, the rest-style usage of some websites is higher than that of soap. However, since rest is just an idea of implementing Resource Operations Based on HTTP protocol, there is a set of rest implementations for each website. The rest API style of each major website will be discussed later. It is precisely because of their respective implementations that the performance and availability will be much higher than the Web Service released by soap, but the unified and universal aspect is far inferior to soap. Because the SP of these large websites often focus on the API development of this website, the general requirements are not high. For the release of rest-style Web Services on ASF, you can refer to the design of several major websites (the solution of brothers is to refer to the design mode similar to that of Flickr ), however, since there is no authoritative protocol similar to soap as a specification, various rest-implemented protocols can only be regarded as private protocols. Of course, they must follow the rest idea, but there are too many constraints in such details. The future development of rest will also directly affect whether the design can have good vitality. In general, soap is better than rest in terms of maturity.
Efficiency and ease of use:The SOAP protocol defines message bodies and headers, And the scalability of message headers provides the basis for extension of various Internet standards. The WS-* series are relatively successful specifications. However, due to the constant expansion of the content of SOAP Protocol due to various requirements, the performance of soap processing has declined. At the same time, it also increases in usability and learning costs. Rest has been paid attention to by people. In fact, it is also very important because of its efficiency and simplicity and ease-of-use features. This efficiency stems from its resource-oriented interface design and operation abstraction, which simplifies developers' poor design and maximizes the use of HTTP's original application protocol design philosophy. At the same time, in my opinion, another attractive developer in rest is that it can well integrate many front-end technologies of current Web2.0 to improve development efficiency. For example, many rest APIs open to large websites have multiple return forms, except for the traditional XML as data bearer and JSON, RSS, atom, and other forms, this is a good way for many front-end website developers to prepare various resource information for mashups. Therefore, rest is superior in terms of efficiency and ease of use.
Security:This can be put into maturity. However, in the current Internet application and platform development and design process, security has been raised to a very high level, especially as an external interface for third-party calls, security may be higher than the business logic itself. In terms of security, soap uses XML-security and XML-signature to form WS-Security to implement security control. Currently, it has been supported by various vendors ,. net, PHP, and Java are already well supported (although some details are still incompatible, it is basically possible to connect ). Rest does not have any specifications to describe security. At the same time, websites that open rest APIs are mainly divided into two types, one is custom security information encapsulated in messages (which is no different from soap), and the other is guaranteed by hardware SSL, however, this only ensures point-to-point security. SSL is powerless if multi-point transmission is required. Security is also a big problem. At the BEA summit this year, we saw a demonstration of the use of saml2 for inter-site SSO. In fact, XML-security and XML-signature were directly used, efficiency does not seem very high. In the future, it is unknown whether the two standards will be used in the rest normalization and generalization processes. However, the more you add, the more advantages that rest will lose its efficiency.
Application Design and Transformation:Our system either has services that need to be released, or services that have just been designed, however, it takes a little time for developers to accept the rest form with their traditional design ideas. At the same time, it is easier to design resource-based data service interfaces according to the rest concept. For some complex service interfaces, it may be far-fetched to design according to the REST style. In fact, you can see the interfaces of various websites. Many websites also need to input the function name as the parameter, which obviously violates the rest design idea. Soap is designed for RPC, which is very easy for developers to accept. Therefore, there is no adaptation process.
In general, it is still an old concept, and the best fit is the bestThere is no good or bad technology, but it is not suitable. If a good technology or idea is misused, it will be reversed. Both rest and soap have their own advantages. At the same time, if you transform rest in some scenarios, it will actually go to soap (such as security ). Rest is suitable for Resource-based service interfaces and especially suitable for scenarios with high efficiency requirements but low security requirements. The maturity of soap can be provided to multiple development languages, facilitating interface design with high security requirements. Therefore, I think it makes no sense to say that the design model will be dominant. The key is to look at the application scenario. At the same time, it is very important not to distort the rest. Many websites are now following the trend in developing restful interfaces. They are actually learning the rest interface. I don't know what it is, and the performance is not good, security is not guaranteed, and there is a seemingly similar leather bag.
Several forms of rest designRefer to the rest-style API design for several large websites. Here is a general description:
Facebook:Request message: the URI design adopts a rest-like style. For example, for obtaining friends, it is defined as friends. get, which is defined as a resource in the previous section, followed by specific operations. Other APIs are similar, resource + operations. Therefore, even if the http get method is used, the update operation may be performed, actually, it is against the idea of rest. However, in the complex business interface design, it is basically impractical to abstract all interfaces through rucd. After the URI is defined, there are also detailed parameter definitions, including the type and whether required. Response message: there are multiple methods, XML and JSON. XML has XSD as a reference. It is a bit similar to soap without a head, but here the XSD that can be defined in the WSDL is extracted.
Flickr:Request Message: http://api.flickr.com/services/rest? Method = Flickr. Test. Echo & name = value here we can see that the customized rest request is actually not much different from RPC. Message return: Correct Response <? XML version = "1.0" encoding = "UTF-8"?> <RSP stat = "OK"> [XML-payload-Here] </RSP> error handling return <? XML version = "1.0" encoding = "UTF-8"?> <RSP stat = "fail"> <err code = "[error-code]" MSG = "[error-message]"/> </RSP> Based on the returned results, we can see that the attack has been violated. with the concept of rest, the HTTP protocol is also used as the transmission bearer protocol, and does not actually use HTTP as the resource access and operation protocol. In general, it's just a form that imitates rest and creates a set of private protocols.
EBay
:Request Message: XML is used as the bearer type, which is similar to soap. However, the encapsulation and header of the SOAP message are removed, and additional information such as the authentication and warning level is added to the request. Message return: similar to a SOAP message, but the soap encapsulation and header are deleted, and additional information such as the message processing result and version is added to the return structure. This is similar to the current practice of the axis2 framework. It simplifies soap and enriches the security, transaction, and other protocols as needed.
Yahoo Maps
:Request Message: http://local.yahooapis.com/MapsService/V1/geocode? Appid = yahoodemo & Street = 701 + first + Ave & City = Sunnyvale & State = Ca adopts the rest recommendation method, Uri + parameters. Response Message: <? XML version = "1.0" encoding = "UTF-8"?> <Resultset xmlns: xsi = "http://www.w3.org/2001/XMLSchema-instance" xmlns = "urn: Yahoo: maps" xsi: schemalocation = "urn: Yahoo: maps http://local.yahooapis.com/MapsService/V1/GeocodeResponse.xsd "> <result precision =" Address "> <latitude> 37.416384 </latitude> <longpolling>-122.024853 </longpolling> <address> 701 First Ave </address> <city> Sunnyvale </city> <State> Ca </State> <zip> 94089-1019 </zip> <country> us </country> </R Esult> </resultset> the simplified XML returned by soap. Other information, such as error codes, is carried by the HTTP header.
YouTube
:Request Message: http://www.youtube.com/api2_rest? Method = YouTube. Users. get_profile & dev_id = your_dev_id & User = youtube_user_name you can see that the URI definition for resource operations is also a part of the parameter. Response Message: <? XML version = "1.0" encoding = "UTF-8"?> <Ut_response status = "OK"> <user_profile> <first_name> YouTube </first_name> <last_name> User </last_name> <about_me> YouTube rocks !! </About_me> <age> 30 </age> <video_upload_count> 7 </video_upload_count> </user_profile> </ut_response> Custom soap messages.
Amazon
:Request Message: https: // Amazon FPS web service end point /? Awsaccesskeyid = Your awsaccesskeyid & timestamp = [current timestamp] & Signature = [Signature calculated from hash of action and timestamp] & signatureversion = [Signature calculated from hash of action and timestamp] & version = [version of the WSDL specified in YYYY-MM-DD format] & Action = [name of the API] & parameter1 = [value of the API parameter1] & parameter2 = [value of the API parameter2] &... [API Parameters And their values] returned message: similar to soap's own protocol, the message body contains additional information such as message status.
Summary:After reading the design of so many websites above, there are several major design methods. Request message design: 1. basically conforms to the rest standard mode: Resource URI definition (resource. Operation) + parameter. If such designs abuse get to handle other types of operations, it is no different from 2. 2. Rest-style Non-rest ideas: Resource URI definition + parameters (including operation method names ). In fact, it is the follow-up of RPC. 3. Similar to a SOAP message, the custom protocol uses XML as the bearer. (Extensible, such as authentication and Access Control), but it is like defining a set of soap and soap extends. Some large and powerful websites adopt this approach. Response Message design: 1. in the standard rest mode, the resource state is transmitted and returned to the client. The HTTP message is used as the application protocol rather than the transmission protocol. XML is used as the message bearer body, HTTP is used as the message transmission protocol, and the processing status is self-contained. 3. Custom message formats, similar to soap, provide extensible parts. The rest concept is followed by the design of response 1 and request 1.
Integration of rest and ASFThere are two suitable methods for integrating ASF with rest. I. it is implemented using the rest of axis2. The advantage of this method is that the development cycle is short and easy to integrate, but the request and response formats cannot be changed, and the resource URI design is limited, the rest of axis2 is actually to streamline the SOAP message, delete the SOAP header during the request, and only return the resource information during the response. If XSD is provided, it can be parsed by various clients. Not really rest. II. the restlet open-source framework is used to integrate the restlet open-source framework into ASF. Because restlet itself is an embedded application framework, integration is not a problem. At the same time, the restlet framework is only an API structure framework, therefore, the implementation and definition are completely separated. After integrating restlet, You can implement the parsing engine by yourself or use the default engine. At the same time, you can support multiple open-source projects, such as embedded jetty, integrate more advantages into rest. After reading this, many domestic friends have already paid attention to the restlet open-source project and read its architecture design. I personally think it is flexible and compact.
DigressBefore writing this article, I wrote a survey report for reference by architects. In the afternoon, I chatted with our chief architect for a moment. Actually, I feel the same as him. Does rest really need to be integrated in our existing service framework, understand the concept of rest, and then look at the application scenario, then we can find that if we want to fully follow the rest design concept to design interfaces, it is strongly necessary to change existing or undeveloped interfaces into technology-oriented technologies, keep pace with the trend. Of course, there is no denying that rest is good. In fact, some interfaces in some business scenarios of our brother company are very suitable for this type of design. Resource-oriented, efficient, concise, and easy-to-use can all reflect its value. We will cooperate with our brothers and refer to their design concepts and release some of them in this form based on the implementation of various websites, ISVs provided to third parties are undoubtedly the best reason for integrating rest into ASF. If we have the need to do this, we will not fall into technology for the sake of technology. After all, technology is driven by commercial value, and society is filled with the advocacy of various technologies, if you do not care about it, you will be in the trend of follow-up.
