One idea about rest

This is just going to use rails to become something, so I started to systematically learn rails. Coincidentally, about two weeks ago, dlee invited me to join Dr. Fielding's translation team on the Rest paper. It can be said that rails and rest are the two most popular words that almost simultaneously squeeze into my life. As I learned about rails and translated [Fielding], I also began to develop some immature ideas about rest. I will share them with you here, and I will also serve as a reference, welcome to the discussion.

First, review the basic concepts of rest. [Fielding] formally defines rest as an architectural style, which consists of an element and a constraint. These concepts are obscure, and we do not need to have a metaphysical understanding of engineering. We only know that rest is a design and development method for network applications, which can reduce development complexity and improve system scalability. Rest puts forward some design concepts and principles:

1. Everything on the network is abstracted as a resource );
2. Each resource corresponds to a unique resource identifier );
3. Operate resources through the general connector interface (generic connector Interface;
4. Operations on resources do not change the resource ID;
5. All operations are stateless ).

For today's most common network applications, resource identifier is a URL and generic connector interface is HTTP. The 4th guidelines are what we often call URL immutability. The resouce in these concepts is the easiest to misunderstand. Resouce does not refer to data, but to Data + specific representation (Representation). This is why the full name of rest is representational state transfer. For example, the data between "the best 10 books sold this month" and "your favorite 10 books" may overlap (if one book is sold well, you like it again ), even identical. However, their representation is different, so they are different resources.

Rest can simplify development because of its introduced architecture constraints. For example, the rest implementation in rails 1.2 limits the number of methods in controller to seven by default: index, show, new, edit, create, update, and destory are actually implemented for curd. Furthermore, rails (which is also a majority of today's network applications) uses HTTP as the generic connector interface. Http limits the operation on a URL to four: get, post, put, and delete.

Rest can improve the scalability of the system because it forces all operations to be stateless, so there is no context constraint. If you want to do distributed and cluster operations, you do not need to consider the context issue. At the same time, it allows the system to effectively use the pool. Another improvement of rest performance comes from the distribution of client and server tasks. The server is only responsible for providing resource and resource-operated services, while the client needs to render itself based on the data and representation in the resource. This reduces the overhead of the server.

Since rest has such advantages, we should embrace it without hesitation! At present, some big cows (like DHH) have already begun to invest in the rest world. What should we people do or think about you? I think we should think about two issues:

1. How to Use rest;
2. The relationship between rest and MVC.

The first question is to assume that rest is the architecture we should adopt and then discuss how to use it. The second question is to explain the relationship between rest and the most widely used MVC, and whether it is complementary or alternative?

Let's talk about the first question, how to use rest. I feel that rest not only brings us a brand new architecture, but also makes an important contribution to a new way of thinking during system development: design the system structure through URL. According to rest, each URL represents a resource, and the entire system is composed of these resources. Therefore, if the URL is well designed, the system structure should also be well designed. For non-master developers, it is always abstract to consider how a system is structured. One of the advantages of test driven development promoted by agile development (I think it is the biggest benefit) is that it can intuitively design system interfaces through testcase. For example, if you have not created a class, compile a testcase. Although the settings cannot be compiled, the method calls in testcase can reflect the required interfaces from the perspective of the class user, this provides an intuitive expression for the class design. This is very similar to designing the system structure through URL in the rest architecture. Although we haven't even implemented a function, we can first design URLs that we think are reasonable. These URLs cannot even connect to any page or action, but they intuitively tell us: this is the way the system accesses the user. Based on these URLs, we can easily design the system structure.

Let me repeat it here:Rest allows us to design the system through URL, just as test driven development allows us to design class interfaces using testcase.

Okay. Since the URL has the following benefits, we will focus on how to design the URL. Network applications usually have hierarchy, like a big tree. We usually hope that the URL can also reflect the hierarchy of resources. For example, for a blog application:/articles indicates all articles, And/articles/1 indicates an article with ID 1, which is intuitive. Unfortunately, the resource structure of network applications will never be so simple. Therefore, people often ask the following question: Can restful URLs overwrite all user requests? For example, how does login restful? How is search restful?

From the concept of rest, all things that can be abstracted as resources can use restful URLs. Therefore, for the above two problems, if login and search can be abstracted as resources, you can use restful URLs. Search is relatively simple, because it returns the search results, so it can be abstracted as a resource, and only the index method can be implemented (only the search results need to be displayed, there is no such thing as create, destory ). However, there is also a question: how can I transmit the search keyword to the server? The index method should obviously use http get, which will add the keyword to the URL, of course, not in line with the REST style. To solve this problem, we can regard each search as a resource. Therefore, we need to create the create and index methods. The create method is used to send the keyword to the server through http post when the user clicks the "Search" button, then 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 look at something more complicated. How to use a URL to express "Classification as Ruby's article "? At first, you may think of/category/Ruby/articles, which is intuitive. However, I don't think the category is needed. We can directly think of "/ruby" as "Category is ruby ", that is to say, the location where "Ruby" appears indicates that it refers to category. OK,/Ruby/articles. From this URL alone, how much information can we get about category? Obviously, category is hidden behind the URL. If this is the case, it should be the benevolent and wise. I have not come up with a good idea about how to express category. You can discuss idea together.

There is also a URL that corresponds to the inheritance relationship in the program. For example, product is a parent class, and book and computer are child classes. The URL of all products should be/products, the URL of all books should be/books, and the URL of all computers should be/computers. This idea is more intuitive, and I once again verified the arguments that URL can help us design.

Let me explain my thoughts:If each user's needs can be abstracted as resources, rest can be fully used.

From this point of view, the key to using rest is how to abstract resources. The more accurate the abstraction, the better the rest application. Therefore, it is most important to change our deeply rooted action-based thinking.

With the discussion of the first question, it is much easier to discuss the second question. Will Rest replace MVC? Or are they complementary (like AOP For OOP )? The answer is it depends! If we can abstract all user needs as resources, then MVC can launch a stage of history. Otherwise, we need to mix rest and MVC.

Of course, this is an ideal argument. We may not be able to find a way to abstract all user needs as resources, because to ensure the integrity of this abstraction (that is, it is true that all requirements are acceptable) requires formal proof. Even if it is proved that, because developers have different abilities and preferences, MVC will certainly become the first choice for many people. But for those who want to embrace rest, it doesn't matter. As long as the problem domains designed by your system can be reasonably abstracted as resources, rest will become your development tool.

Therefore, all friends who want to embrace rest should train themselves to see the world with glasses of resources. This is the core of rest. 

Reproduced from the javaeye Forum by allenyoung

Address: http://www.javaeye.com/topic/70113