REST constraints are based on the basic principles of WEB control. These principles are:
- User agents interact with resources, and anything that can be named and expressed can be called a resource. Each resource has a unique Uniform Resource Identifier (URI).
- The interaction with the resource (through its unique URI location) is done using the unified interface of the HTTP standard verbs (GET, POST, PUT, and DELETE). It is also important to declare the media type of the resource in the interaction, which is specified using the HTTP content type header. (XHTML, XML, JPG, PNG, and JSON are some of the most widely known media types.) ）
- Resources are self-describing. All the information required to process a resource request is contained within the request itself (so that the service can have no state).
- The resource contains links to other resources (hypermedia).
Why should you focus on REST? Now that I have some explanation for REST, you may be wondering why you should pay attention to it. As a developer, you need a certain motivation to learn and adopt any style, technique, or pattern. If you read this magazine, you may be a developer who often deals with Microsoft technologies. To implement a client-server application, you may be using a different architectural style: Remote Procedure call (RPC). Whether you are using a dedicated RPC system (such as DCOM or.
NET Remoting), or interoperable RPC technology (for example, using an
the SOAP for ASMX or WCF), which are all client-server styles presented on the Microsoft platform. So why study or use REST? As far as I know, there are two main reasons. First, the important functions and advantages of REST in many ways are much better than
RPCTechnology. Second, Microsoft is moving many of its implementations from RPC technology (such as SOAP) to REST. This means that even if you are hesitant about building your own system with rest, you still need to know how to interact with Microsoft and other companies as they move more frameworks and technologies to REST. The following is a list of other benefits (not all of the benefits are listed):when the
cache uses HTTP to request data to the RESTful endpoint, the HTTP verb used is get. The resources returned in a GET request response can be cached in a number of different ways. Conditional GET is an implementation detail to choose from, and the client can verify to the service whether his data is up to date, and the RESTful endpoint can further improve speed and scalability through it.
Extended REST encourages each resource to contain all the necessary states required to handle special requests. When this constraint is met, RESTful services are easier to scale and can be stateless. side Effects If you use GET request resources, RESTful services should have no side effects (unfortunately, this constraint is easier to break than some rest constraints).
idempotent Unified Interface The other two main HTTP verbs are PUT and DELETE. The most common use of put,delete when user agents want to modify resources is to describe themselves. The main point (the term "idempotent" emphasizes) is that you can use the two verbs multiple times for special resources, the same as for first use-at least without any other effect. This benefit is guaranteed when a reliable distributed system is built (that is, errors, network failures, or delays can lead to multiple code execution).
Interoperability Many people are holding SOAP as the most interoperable way to establish client-server programs. However, some languages and environments do not yet have a SOAP toolkit. There are some toolkits, but the old standard is not guaranteed to communicate reliably with the toolkit using the update standard. For most operations, REST requires only HTTP libraries (and, of course, XML libraries are often helpful), and its interoperability is certainly stronger than any RCP technology (including SOAP). simplicity is more subjective than other advantages, and different people may have different feelings. For me, the simplicity of using REST involves the URI representing the resource and the unified interface. As a Web surfer whiz, I understand that entering different URIs in a browser can get different resources (sometimes referred to as URIs or URL hackers, but no malice). Because of the experience of using URIs for many years, designing URIs for resources is handy for me. Using a unified interface simplifies the development process because I don't have to build interfaces, conventions, or APIs for every service that needs to be built. The interface (the way the client interacts with my service) is set by the architecture constraints. As I said, this is not an exhaustive list, and you cannot assume that REST is the only technology that is often used. You should be aware of its strengths so that it can be leveraged when needed. Currently, WCF can also complete the RESTful functional architecture programming model with the following new features two main new properties: WebGetAttribute and WebInvokeAttribute; there is also a URI template mechanism that helps you declare the URI and verb for each method response. The composition of the infrastructure is a binding (webhttpbinding) and a behavior (WebHttpBehavior) that provides a suitable networking stack for using REST. In addition, custom ServiceHost (Webservicehost) and ServiceHostFactory (webservicehostfactory) also provide some help with hosting infrastructure.
RESTful service Architecture style *. NET's restful framework Openrasta
