From: The changes brought by IBM SOAP 1.2 further woven the web service to the Internet of Internet. One of the changes is the introduction of the GET method. Get is important because it supports various optimizations. This has been verified by Web itself, which uses a GET method extensively. This skill can be further understood.
Soap 1.0 has been released, many people have complained that it is dependent on the HTTP Post method. Many people think that SOAP uses a popular protocol (HTTP), but does not consider and understand the architecture established there.
The 1.2 version of W3C hosted development solved this problem. W3C has spent a lot of relief in many aspects of the agreement, making it easier to use this agreement through a variety of different technologies. By revision, SOAP 1.2 supports SMTP in addition to HTTP, and can better utilize HTTP.
What is the problem with post method POST? Briefly, HTTP defines different ways to interact with the server, the most basic method is GET and POST. In fact, the GET is suitable for most requests, and the POST is only used to update the site. According to the HTTP specification, GET is used for information acquisition, and should be safe and power.
Here, the so-called security means that the operation is used to obtain information rather than modifying information. In other words, GET requests generally should not generate side effects. Power, etc., it means that multiple requests to the same URL should return the same result. Complete definition is not as strict as it looks like. Fundamentally, the goal is that when the user opens a link, she can be sure to see the resources from their own perspective. For example, the header of the news site is constantly updated. Although the second request will return a different batch of news, this operation is still considered safe and power, because it always returns the current news. vice versa. POST request is not so easy. POST indicates a request to change the resources on the server. Still in the news site as an example, the reader's annotation of the article should be implemented through the POST request, because the site has been different after the annotation is submitted (a note appears below). The difference between GET and POST is not always so strict, there are some commonality. Many sites encapsulated simple information acquisition in the Post request, which may be because developers think this is simpler. Although the discussion of the HTTP method seems to be abstract and theoretical, not this. Browser and Mediation Software (Agents, Firewalls and Content Submission Solutions La Akamai) Get optimized performance according to distinguishes different request capabilities (see Resources). SOAP Alliance GetSoAP initially only supports POST request. Web services can still achieve the above-mentioned security services. For example, the service of query orders is both secure and power. According to the HTTP specification, it should be implemented as a GET request. The POST must be used according to SOAP 1.0. SOAP 1.2 introduces Message Exchange Patterns, MEPS and a new HTTP binding. The combination of the two can achieve the Web service that responds to GET requests. MEP describes the interaction mode between customers and servers. SOAP REQUEST-RESPONSE MEP is a typical web service interaction: the customer issues a request to the server, the server answers. I will further examine SOAP RESPONSE MEP. MEP only defines a response without request. In practice, this means that the request has been issued, but not the SOAP request, only the response is SOAP. When combined with the new HTTP request, Response MEP can support GET requests. The principle of its work is as follows:
The customer issued a GET request. It sets the Accept header to Application / SOAP XML to request a SOAP reply. The server replies, the customer will respond to normal SOAP response processing. The server distinguishes SOAP requests and regular HTML requests via Accept headers. Customers can use Q attributes in ACCEPT to set different Content / Type to indicate their parameter selection. Depending on the needs of the service, the customer can include parameters in the URL through a general URL encoding method (usually after the characters). For example, services that report the status of the farm may not require any parameters. According to the definition, it returns the status of the current server. Instead, the reportable product availability and price requires the product identifier (or name) as a parameter. Now you may confuse how customers know which URL calls and which parameters pass, because the request is not part of SOAP. The answer is simple: the SOAP server should complete the work made by the General Web server and contain the URL in the last interaction. Nothing hinders GET and POST mixing and matching. As an example, imagine a service for handling office supplies (pen, paper, scissors, etc.). The service receives orders through SOAP, apparent that such a request is neither secure, and is therefore issued as a POST. The server's response can contain a URL to track the processing of the order. Tracking is safe and power, so it is best to be implemented. AXIS and WSDL support When writing this article, AXIS only supports SOAP 1.1, but there is still a limited GET form. You can call any request through its URL, followed by a Method parameter and other parameters. For example, suppose that you have implemented an order status service in URL http://joker.psol.com/axis/order/status.jws. This service has two methods, TRACK and DETAILTRACK, as an order number (Onumber) as a parameter. I can call the service via http://joker.psol.com/axis/order/status.jws?method=track&onumber=56544322. WSDL 2.0 (W3C is being developed) Added Pattern attributes in the operational definition. This attribute indicates which SOAP MEP (WSDL call MEP mode is not confusing between SOAP and WSDL). For example, the tracking service can be defined as Listing 1. Listing 1. WSDL excerpt
The simple principle behind the end of the text has proven its own flexibility and reliability. As one of the most important criteria in Web services, SOAP is a very positive progress of this is a very positive development of this extraordinary success. Before waiting for the favorite kit to upgrade to SOAP 1.2 and WSDL 2.0, check your web service first, identify the security operations that migrate to get binding as the primary goal. Reference
