Http,soap and Rest

Http://www.cnblogs.com/hyhnet/archive/2016/06/28/5624422.html

HTTP is a standard Hypertext Transfer protocol. The associated request semantics are also used, using encoding parameters and passing parameters as key-value pairs. Each protocol contains a series of HTTP request headers and other information that defines what the client requests to the server, and the server responds with a series of HTTP response headers and the requested data. Http-get uses the MIME type application/x-www-form-urlencoded (which is appended to the URL of the server that handles the request) to pass its parameters as URL-encoded text. URL encoding is a form of character encoding that ensures that the passed arguments contain consistent text, such as encoding spaces as%20, and other symbols to%xx, where XX is the ASCII (or ISOLatin-1) value of the symbol in 16 notation. The appended parameters are also called query strings; The Http-post parameter is also URL-encoded, but the key/value pair is passed inside the actual HTTP request message, not as part of the URL.

SOAP(Simple Object Accessprotocol) is an access protocol. It is a lightweight protocol for exchanging information in a decentralized, distributed computing environment. SOAP helps to access objects, services, and servers in a platform-independent manner. It uses XMLto provide the extensions required by HTTP.

The SOAP protocol specification consists of 4 main parts.

Part I: TheSOAP wrapper (Envelop) defines a framework that describes how much content a message is, who sends it, who should accept it, how it is handled, and how to handle it.

Part II: TheSOAP Coding Rules (Encoding rules) define optional data encoding rules that represent application-defined data types and direct charts, and a uniform standard for serializing non-grammatical data models.

Part III:The SOAP RPC representation (RPC representation) defines a pattern for a remote call style (Request / response) information exchange.

Part IV: Thesoap binding (binding) defines the binding between soap and HTTP and the exchange using the underlying protocol.

The SOAP protocol can be easily understood as:Soap=rpc+http+xml, which uses HTTP as the communication protocol,RPC(Remote Procedure Call Protocol-Remote Procedure Call protocol) as a consistent invocation path,XML is used as a format for data transfer, allowing service providers and service clients to communicate over the Internet through firewalls .

REST (representational state Transfer) is a lightweight Web service architecture . Can be implemented entirely through the HTTP protocol. Its implementations and operations are more concise than soap and XML-RPC, and cache caches can be used to improve responsiveness, with better performance, efficiency, and ease of use than the SOAP protocol.
The rest schema's operations on resources, including fetching, creating, modifying, and deleting resources, correspond exactly to the get, POST, put, and Delete methods provided by the HTTP protocol

The difference between SOAP and HTTP

Web Service relative HTTP (post/get) may be slow due to XML parsing.

Web service can be completely replaced by HTTP (post/get).

The difference between restful and soap

Security: SOAP is better than restful

Efficiency and ease of use (rest wins)

Maturity (overall soap is better than rest in terms of maturity)

a REST:

Rest is an architectural style whose core is resource-oriented, and rest is designed and developed for network applications to reduce the complexity of development and improve the scalability of the system.

　　Rest presents design concepts and guidelines for:
1. Everything on the network can be abstracted as a resource (Resource)
2. Each resource has a unique resource identifier (resource identifier), and the operation of the resource does not change these identities
3. All operations are non-stateful

Rest simplifies development and its architecture follows the CRUD principle, which tells us that only four behaviors are required for resources (including network resources): Create, Fetch, update, and delete to complete related operations and processes. You can identify and locate resources through a Uniform Resource identifier (Universal Resource Identifier,uri), and the actions that are performed on those resources are defined through the HTTP specification. Its core operation is only Get,put,post,delete.

Since rest enforces that all operations must be stateless, there is no context constraint, and if distributed, the cluster does not need to consider the problem of context and session retention. Greatly improve the scalability of the system.

two SOAP

SOAP is biased towards activity-oriented, with strict specifications and standards, including security, transactions and other aspects of the content.

Soap emphasizes the separation of action methods and operands, which are defined separately by the WSDL file specification and the XSD file.

While rest emphasizes resource-oriented, we can use the rest architecture style as long as the objects we want to manipulate can be abstracted as resources.

　　How to determine the use of rest:

Abstract resources are easier if they are simply crud business operations.

Abstract resources for complex business activities are not a simple matter, such as verifying user levels, transferring money, and dealing with transactions.
　　How to determine the use of soap:
If there are strict specifications and standard definition requirements, and need to guide the integration and development of multiple business systems in the prior period,

Soap is more appropriate because the SOAP style has a clear specification standard definition.

We can strictly define the relevant interface methods and interfaces to transfer data before starting and implementing them.
　One word:

Simple data manipulation, no transaction processing, development and invocation simple to use rest architecture style is better.

　　Furthermore:
　　　　The REST core is URL and resource-oriented, and the URL replaces the original complex operation method.

　　　　REST allows us to design the system through a URL, just as test-driven development uses a test case design class interface.

All things that can be abstracted into resources can use restful URLs.

　　Rest key:
The key to using rest is how to abstract resources, the more accurate the abstraction, the better the rest application.

———————————————————————————————————————

Three rest ideas

　　1. Resource-oriented interface design

All interface designs are designed for resources (including operations as well as resources).

The design of URIs also embodies the positioning of resources.

　　2. Abstract operations-based CRUD

The get,put,post,delete in HTTP correspond to the Read,update,create,delete four operations respectively

If it is just as a resource operation, the abstraction is enough for these four kinds, but for complex business interfaces, it may not be able to be satisfied.

Designed entirely according to rest, the applicable environment will be limited, not universally.

　　3. HTTP is an application protocol rather than a transport protocol

Part of the idea is that rest is designed as a private soap protocol, so called a restful custom soap protocol.

　　4. No status, self-contained

Interface design needs to do this, not just rest, but also as the most basic guarantee of scalability and efficiency, soap is similar.

Four comparison of SOAP WebService and restful WebService

　　1. Maturity (overall soap is better than rest in terms of maturity)

Soap has reached a mature situation for the release and invocation of heterogeneous environment services, as well as vendor support.

Rest many large web sites have published their own development APIs, many of which provide soap and rest two web Service,

But since rest is just an idea for resource manipulation based on the HTTP protocol, the rest implementation of each website has its own set.

The various protocols that rest implements are only private agreements, and of course need to follow the thought of rest.

2. Efficiency and ease of use (rest wins)

　　　　The SOAP protocol defines both the message body and the message header, while the extensibility of the message header provides an extended basis for the various Internet standards.

The WS-* series is a more successful specification. But also because of the need for soap to constantly expand its own protocol content, resulting in soap

Performance has decreased in terms of processing. There has also been an increase in ease of use and learning costs.

　　　　REST is a big part of people's attention, but also because of its high efficiency and simple and easy-to-use features.

This efficiency stems from its resource-oriented interface design and operational abstraction that simplifies the developer's bad design.

It also maximizes the use of HTTP's initial application protocol design concept.

At the same time, rest is a good blend of current Web2.0 's many front-end technologies to improve development efficiency.

　　　　　　For example , many large Web sites open restful APIs will have multiple return forms (Xml,json,rss,atom).

　　3. Security

　　　　SOAP uses the xml-security and xml-signature two specifications in security to achieve security control, which is composed of a ws-security.

Currently, it has been supported by various vendors and has been well supported by. NET, PHP, and Java.

　　　　The rest -Open Rest-style API's Web site is divided into two main types:

One is to customize the security information encapsulated in the message,

The other is to rely on hardware SSL to protect, this can only guarantee point-to-points security, if the need for more transmission, SSL can do nothing.

The safety of this piece is actually a big problem.

Five application design and retrofit

Our system either already has the services that need to be published or is just designed, but the traditional design ideas of the developers will take a little time to accept the form of rest. At the same time in the resource-based data service interface design in accordance with the rest of the idea of design is relatively easy, and for some complex service interface, may be strong to follow the rest of the style of design will be a bit far-fetched. This point can actually look at the interface of the major sites can be known, many sites also have to pass in the name of function as parameters, which clearly has violated the rest of the design ideas. and soap itself is designed for RPC, developers are very easy to accept, so there is no adaptation of the process. In general, is still an old concept, suitable is the best

The technology is not good or bad, only if it is appropriate, a great technology and ideas have been misused, then it will be counterproductive. Rest and soap each have their own merits, and if you are going to transform rest in some scenarios, you will actually move to soap (for example, security).

Rest is appropriate for resource-based service interfaces, and is particularly well suited for scenarios where the requirements for efficiency are high, but not for the security requirements. However, the maturity of soap can be provided to many developing languages, which facilitates the design of interfaces with high security requirements. So I think it's pointless to just say what design patterns will dominate, and the key is to look at the application scenario.

At the same time it is important to not distort the rest now many Web sites are the follow-up to develop a rest-style interface, in fact, are learning its shape, do not know its heart, finally made no fish and fish, performance, security and can not guarantee, the apostles have a look like a sample of the skin.

Http,soap and Rest