A little idea of rest

I was planning to do something with rails, so I started to learn rails in a systematic way. Coincidentally, about two weeks ago, Dlee invited me to join Dr. Fielding's translation team for the rest essay. It can be said that the two hottest words, rails and rest, have squeezed into my life almost at the same time. With my study of rails and my translation of [Fielding], I began to have some immature ideas about rest, to share it with you, and also to play a role, and welcome the discussion.

Let's review the basic idea of rest. [Fielding] formally defines rest as an architectural style (architecture style), which consists of a schema element (element) and a schema constraint (constraint). These concepts are obscure and difficult to understand, and often we do not need a metaphysical understanding of engineering. We only know that rest is a design and development approach to network applications that reduces the complexity of development and increases the scalability of the system. Rest presents some design concepts and guidelines:
Everything on the network is abstracted as a resource (resource), each resource corresponds to a unique resource identifier (resource identifier), and the resource is manipulated through a generic connector interface (generic connector interface); The various operations on the resource do not change the resource identity; All operations are stateless (stateless). For today's most common network applications, resource identifier is Url,generic Connector interface is HTTP, and the 4th rule is the URL invariance we often say. The resouce of these concepts are most likely to cause misunderstanding. Resouce refers not to data, but to data + specific representations (representation), which is why the full name of rest is the reason why representational state transfer. For example, the "best selling 10 books of the Month" and "your favorite 10 books" may overlap on the data (one book sells well and you like), or even exactly the same. But they have different representation, so they are different resource.

Rest simplifies development because of the architectural constraints it introduces, such as the implementation of rest in rails 1.2 By default limiting the methods in the controller to 7: Index, show, new, edit, create, update, and Destory, This is actually the realization of curd. Further, Rails (and most of today's Web applications) uses HTTP as the generic connector interface,http restricts the operation of one URL to 4: GET, POST, put, and delete.

Rest is able to improve the scalability of the system, because it forces all operations are stateless, so there is no context constraints, if you want to do distributed, cluster, there is no need to consider the context of the problem. At the same time, it makes it possible for the system to use pool effectively. Another rest performance boost comes from its assignment to client and server tasks: Server is only responsible for providing resource and operating resource services. The client should make the render according to the data and representation in resource. This reduces the overhead of the server.

Since rest has such an advantage, we should embrace it with no hesitation. Now some Daniel (like DHH) has started to devote to rest of the world, what should we people do or think about what you write. I think we should think about two things:
How to use rest and the relationship between rest and MVC.

The first question assumes that rest is the schema we should adopt, and then we discuss how to use it, and the second question is what is the relationship between rest and the current most commonly used MVC, complementary or superseded.

Let's start with the first question, how to use rest. I feel that rest in addition to bringing us a new architecture, there is an important contribution to the development of the system in the process of a novel way of thinking: through the URL to design the structure of the system. According to rest, each URL represents a resource, and the entire system is made up of these resource. Therefore, if the URL is well-designed, then the structure of the system should also be well-designed. For developers who are not a master level, it is always a very abstract question to consider how a system is architected. One of the benefits of the test driven development advocated by Agile development (which I think is the greatest benefit) is the ability to visually design the interface of the system through testcase. For example, when you have not created a class to write a testcase, although the settings can not be compiled, but the TestCase in the method call can be very good from the class user's point of view to reflect the required interface, thus providing a visual representation of the class design. This is very similar to designing the system structure through URLs in the rest architecture. Even though we don't have a single feature, we can design URLs that we think are reasonable, and they can't even connect to any page or action, but they tell us intuitively that the system should have access to the user's interface. Based on these URLs, we can easily design the structure of the system.

Let me reiterate here again:rest allows us to design the system via a URL, just like the test driven development allows us to design the class interface using TestCase.

OK, since the URL has this benefit, let's focus on how to design the URL. Web applications are usually hierarchy, like a big tree. We usually want URLs to reflect the hierarchy of resources. For example, for a blog application:/articles represents all the articles,/ARTICLES/1 represents the ID 1 of the article, which is more intuitive. Unfortunately, the resource structure of network applications is never so simple. So people often ask the question: Can a restful URL overwrite all user requests? For example, how is login restful. Search how to be restful.

From the concept of rest, all the things that can be abstracted into resources can use restful URLs. So for the above two problems, if login and search can be abstracted as resources, then you can use RESTful URLs. Search is simple because it returns search results, so it can be abstracted as a resource, and only the index method can be implemented (just show search results, no create, destory, etc.). However, there is also a question: How to pass the keyword of search to the server. The index method should obviously use HTTP GET, which adds the keyword to the URL, which is certainly not a restful style. To solve this problem, you can think of each search as a resource, so create and index methods are created so that when the user taps the "search" button, the keyword is passed to the server via HTTP POST, and index is used to display the search results. In this way, we can also record the user's search history. Using the same method, we can also apply rest to login, that is, each login action is a resource.

Now, let's get some more complicated stuff. How to use the URL to express "category is Ruby's article". It is intuitive to think of/category/ruby/articles at first. But I think the category is not necessary, we can directly understand "/ruby" as "category is Ruby", that is, "Ruby" appears in the position that it refers to the category. Ok,/ruby/articles, from this URL alone, how much information can we get about category? Obviously category hidden behind the URL, this is not good, should be the same, benevolent see. I haven't come up with a good idea of how to express a category like this, and everyone has a good idea and can discuss it together.

There is also a URL form that corresponds to the inheritance relationship in the program. For example, product is a parent class, and book and computer are its subclasses. Then all the product URL should be/products, all the book URL should be/books, all the computer URL should be/computers. The idea is straightforward and again validates the argument that URLs can help us design.

Let me explain my idea again:if each user requirement can be abstracted as a resource, then rest can be used completely.

As a result, the key to using rest is how to abstract resources, the more accurate the abstraction, the better the application of rest. Therefore, how to change our deeply rooted action-based thinking is of paramount importance.

With the discussion of the first question, the second question is much easier to discuss. Does rest replace MVC? Or are they complementary to each other (like AOP for OOP). The answer is it depends. If we can abstract all the user needs into resources, then MVC will be able to roll out the stage of history. If the reverse is the case, then we need to mix rest and MVC.

Of course, this is a very good argument. Perhaps we cannot find a way to abstract all user requirements into resources, because it is necessary to ensure that the abstract integrity (that is, all the requirements are true) needs to be formalized. And even if it proves that, because of the developer's ability and preferences, MVC will certainly become the first choice for many people. But for those who want to embrace rest, none of this is related. As long as the problem domain that you develop is designed to be reasonably abstracted as a resource, then rest becomes your development weapon.

So, all the friends who want to embrace rest, quickly train themselves how to take the resources of the glasses to see the world, this is the core of rest.

Reprinted from Javaeye Forum Author: Allenyoung

Original address: http://www.javaeye.com/topic/70113