Answer 10 questions about rest

After you've learned about rest, you'll want to know how useful this concept is in your practical application. And if you're already familiar with a different set of architectural practices, so you're worried about whether "rest" or "rest" http (RESTful http) is really going to work in practice, or not in the introductory, ' Hello, world ' scenario. I'm going to be in this article to answer people--especially those who are familiar with the SOAP/WSDL Web services architecture--of the 10-point puzzle about rest that comes easily when you start studying rest.

1.REST may apply to crud, but does not apply to "real" business logic

This is the most common reaction to those who are skeptical about the benefits of rest. After all, if you can only create/read/update/delete, how do you express more complex application semantics? I have explored these concerns in this introductory article in this series, but this is definitely worth further discussion.

First, HTTP verbs (verbs)--get, put, post, and delete--are not one by one corresponding to the CRUD operations of the database. For example, both post and put can be used to create new resources, which differ in that they are the URI of a resource that is determined by the client (created or updated), and the POST request is issued to a "collection (collection)" or "Factory (Factory)" Resource. The URI is assigned by the server. But anyway, let's go back to that question: how do we deal with more complex business logic?

Any computed calc (A, B) that returns a result C can be converted to a uri--that identifies its result, such as x = Calc (2,3), which can be converted to http://example.com/calculation?a=2&b=3. At first glance, this seems like a completely wrong use of restful HTTP--we should use URIs to identify the resource (resources) rather than the operation (operations), right? Yes, that's what you do: Http://example.com/sum?augend=2&addend=3 identifies a resource, the result of 2 plus 3. In this particular (apparently well-designed) example, getting is a good idea to get the results of a calculation--after all, it's cacheable (cacheable), and you can reference it, and the calculation is mostly safe and expensive.

Of course, in many (if not most) cases, using get to perform calculations may be a mistake. Don't forget, get should be a "safe" operation, that is, if the client simply follows a link by issuing a GET request, then it assumes no obligations (such as paying you for using your service) or responsibility. Therefore, in many other cases, it is more appropriate to "provide input data to the server through a POST request so that the server can create a new resource." The server can give the URI of the result when it is on the POST request (and it is possible to initiate a redirect to turn you over). The result can then be reused, bookmarked, cached, and so on. You can basically extend this model to any operation that produces results-it covers almost everything you can think of.

2. No formal language of contract and description

From RPC to CORBA, from DCOM to Web services, we are accustomed to having an interface description of "listing operations, names, and input and output parameter types" (interface description). How does rest work without an interface to describe the language?

There are three answers to this question, which is very frequently asked.

First, if you decide to use XML (which is a common practice) to match restful HTTP, then the various existing XML Schema languages (schema languages, such as DTDs, XML schemas, RELAX NG, Schematron, etc.) Still available for you to use. It can be said that a WSDL description of something, often 95% of the content is not related to WSDL, but with your definition of XML Schema complex type (complex types) related. The increase in WSDL is mostly about operations (operations) and their names--for the unified interface to rest (uniform interface), it's rather boring to describe these, because get, put, Post and delete are all the operations you can use. With regard to the use of XML schemas, this means that even if you rely on a restful interface, you can still use your preferred data binding tool (if you have it) to generate data-binding code for your preferred language. (The answer is not finished, see below.) ）

Second, ask yourself what you need to describe. The most common (albeit not unique) Use cases are: The description is used to generate the pile (stubs) and skeleton (skeletons) code for the interface. It is not usually a document (documentation) because the description of the WSDL format does not tell you the semantics of the operation-it simply tells you the name of the operation. You have to learn how to invoke it through some human-readable documents. A typical rest practice is that you should provide HTML-formatted documents that might contain direct links to your resources. If you take the practice of providing multiple representations (multiple representations) then you can really have a document (self-documenting) resource-you simply make an HTTP GET request to a resource in the browser, You can get an HTML document that contains not only the data, but also the list of actions you can perform on it (the HTTP verb) and the type of content it accepts and returns (types).

Finally, if you insist on using a descriptive language for your rest-style service (RESTful services), you can use WADL (Web application Description language,web Application Description Language), or use WSDL appropriately 2.0 (its makers claim that it can also describe rest-style services). However, WADL and WSDL 2 are not helpful in describing Hypermedia (hypermedia)-and, given that this is one of the core aspects of rest, I am not sure that they are fully useful.

3. Who really exposes so much of the implementation details of their applications?

Another issue of general concern is the low level of resources (low-level), which exposes the implementation details that should not be exposed. In the final analysis, does this not add the burden of "using resources in a meaningful way" to the client (consumer)?

The simple answer is: No. The implementation of a resource's get, put, or other method can be as complex as the implementation of a "service" or RPC operation. Applying the rest design principle does not mean that you have to expose the items in the underlying data model (underlying)-it only means that you adopt a data-centric (data-centric) approach, Instead of exposing the business logic in an operationally centric (operation-centric) way.

A related concern is that direct access to resources is not supported to increase security. This is the conclusion of the old fallacy of "secure by stealth" (security by obscurity). One can argue that, on the contrary, if you hide what resources you access through application-specific protocols, you will not be able to use the infrastructure (infrastructure) to protect them. By assigning a separate URI for meaningful resources, you can take advantage of the Apache security rules (and rewrite logic, logs, and statistics) to handle different resources differently. By clarifying these, your security will be enhanced, not reduced.