Exploring the world of resources in Rails-translation of David Heinemeier Hansson's speech in July 9 (Part)

(Translator's note: At railsconf July this year held in February 2006, David Heinemeier Hasson gave a keynote speech about the rest design in rails 1.2, and the rest style brings about innovations in Web application design. The first time I saw this video, I thought it could be a historical presentation on Web server development. At that time, I listened to the speech and translated the speech into nearly 3000 words, which accounted for about 1/4 of the speech space. Later, when I got busy, I had no time to finish the translation. This article had been crawled on my hard drive for more than two months. It was not thrown away, but it was incomplete. Now rails 1.2 has been released. I think more and more web developers will go back and care about the content of this speech, so I suddenly came up with an idea, can you put this incomplete translation on your blog? Could you have time and energy to relay the translation work?

Therefore, I have already put the first part of my translation (the first and second sections of the video) Here. Please check the video content with enthusiastic friends to relay the translation, introduce this major innovation in Web development ideas to Web developers in China .)

Video address: here

Slide address: here

Hello everyone, my speech tonight is "exploring the world of resources in Rails". However, before I give this tutorial, I want to take a few minutes to show my arrogance. I always want to make comments that make people uncomfortable. Now this is almost a tradition.

This Conference presents the most exciting things found by rails developers around the world over the past six months, people outside our small circle have finally begun to focus on the rails community, which is of course cool. But at the same time, we must also think clearly, why do we get such attention? I have heard Thomas's speech yesterday and today. Of course, he has a lot of ideas and suggestions, but at the same time, we should remember that today we will meet here, the reason why rails is today's rails is precisely because we say "no" to many things, just because we have rejected many people. Nowadays, rails is accepted by more and more people, but I do not think that we can deviate from the previous principles. Therefore, although I have undoubtedly supported Thomas's many practical suggestions, he does not agree with his arguments. I don't think rails should give in to the external world. On the contrary, rails is forcing the external world to give in to us. In this speech, I want to talk about the world. I mean, the real world. Many of you probably know that I never think the real world is a comfortable place, but I have a special liking for the ideal world. Rails mostly lives in an ideal world, where rails does not have the shackles of the damn real world. Unfortunately, people must live in the real world, and living in the real world is quite sad. In the real world, you will be dragged into the abyss by decades of experience. This is by no means the path to rails's growth and will not be its future destiny. I will return to this point later.

We recommend that you first report the news. I recently went to Japan, where I was very interested in what happened. Here, we have about three or five hundred people together, representing the rails user base in the Western world. In Japan, Ruby has a large user base and is enthusiastic. They have done a lot of Ruby and rails-related work, many of which I have never heard, it is much more work than people in our small room. They are creating several more ideal worlds, greatly surpassing the one I once dreamed. The book Thomas and I wrote has bought more than 50 thousand since its release last year, which is often used to mark rails's success. In Japan, this book has just been translated and published for a few months and has been sold for more than million books. They have three more books to be published soon. In the English world, about 10 more books will be listed by the end of the year, which is exciting. The news from those teams who have been using rails for a long time is equally exciting. The 43things.com team I mentioned many times applied rails on a large scale and carried out high load tests on public site platforms. The last time I asked them, their rails applications had to generate 3.5 million dynamic webpages every day, which is already a great deal! Of course, this speech is not intended to take more time to boast about itself. The topic of this speech is related to crud.

Crud -- create, read, update, and delete. These words summarize our main work. These basic concepts summarize the main operations we can perform on objects in an object space or database table wrapper. But there is a problem with crud. What's the problem? The problem with crud is that its name is not good. Not only is the name not good, but also has a bad reputation. What do they say about crud? First of all, they said that crud is too simple to rely only on these four operations. Don't expect to do anything interesting. The world is too complicated and cannot be described by these four verbs, so crud is too simple. Crud is too simple to be competent for real work. If you just use crud, you cannot do it. Crud is not a satisfactory method. It cannot fully utilize the remarkable wisdom of mankind. They said that this is not worth it. You should not waste your energy on these four verbs. They are too simple. We should be ashamed to use crud.

They are wrong. My speech today is to eliminate everyone's worries about crud and let everyone learn to fall in love with crud like I do.

In the world of objects, crud. In the database world, we also have four basic operations: Select, insert, update, and delete. However, the four operations in the database world have been around for many years, and the crud statement is too simple, largely due to the comparison with the four operations in the database. So this does not make me think deeply about the crud issue. It prompted me to think deeply about HTTP.

In recent years, we have experienced a Renaissance (Renaissance) and an HTTP renaissance. HTTP has four verbs: Get, post, put, and delete, therefore, a new layer is added to the above crud stack. However, most of us only use get and post to think about HTTP and the Web, without thinking that the four HTTP verbs have made it a new form of crud. I personally feel deeply guilty about this, because over the years I have been deceiving myself that HTTP only has get and post. For this reason, I will spend an hour talking about the following content.

<Page 8th>

Please refer to the following link for more information. When you want to create something, you want to post a specific URL address; when you want to get the object content, put the location of the relevant resource in the URL, and then get; when you want to change this object, you can use post. Some people also use get operations to do this. In fact, this is not good. The delete operation also uses post.

Looking at such a picture, sometimes I feel a little crazy. One of our purposes in rails is to dry and never repeat the work. Let's take a look at the verbs, get, post, and URL here. isn't what we do exactly repetitive work? Let's look at the second line. We say we want to get 1st people, but this people URL contains show, get, and show. Isn't the two exactly the same meaning? Obviously, we have done something wrong. The root cause of these mistakes is that we did not make good use of the crud operations provided by HTTP. If we can make good use, we can make things fresh and beautiful, like this: <9th page>

Now, the URL only identifies the object we are interested in, and the operations we want to perform on the object are expressed by four verbs. Previously, we mixed operation and operation objects, and now clearly separated. This is obviously much more beautiful, but why didn't we do this before? Why is the HTTP capability always forgotten in the corner? There is a reason for this. The reason is that it is very painful to do so, because HTML and other existing things in the web world do not appreciate the existing beauty in HTTP, therefore, no corresponding design implementation is made. Since the purpose of the rails framework is to expose these cumbersome things to the world, why can't we try to solve this problem? This is what I want to talk about today. How can we turn the redundant form above into the refreshing and beautiful form below. In fact, this is not just a question of whether the URL is beautiful or not.

In rails 1.2, if you want to expose a resource so that users can access and operate resources in a refreshing URL, you only need to do this.: <Page 10th>

This statement uses person as a resource, allowing the preceding URL to be mapped directly to the corresponding method.

(There is an explanation of the slides below, skipped ).

How can we achieve this? First, you must increase the put capability and pass it to the Controller. But as I said before, HTML is not easy because it does not have the put capability. It doesn't matter. We need to fix this.

<Page 11th>

The first is post and get, which are the same as before, so there is nothing special to say. The interesting part is update and destroy. In the update section, we need to find a way to tell rails that the action of this form is not a conventional POST method, but a put. This operation should look like this operation. If HTML forms support the put method, we should have written it like this. Unfortunately, this is not the case (HTML forms do not support put actions), so we can only use post to forge a put. In rails, when you write this code, the generated form contains a hidden field called underscored method (underline method ), this underline method will call the method of the real officer. By doing so, we can convince rails that this post is actually a put.

(The above translation is the content of Video 1 and 2. Please be enthusiastic about the translation of the Post)