Aquesta és una revisió antiga del document —-
1.1 Python Professional Course Series: RESTful APIs
Some words about REST
The word you see below may look a little enigmatic: REST
Are we going to convince you to take a rest? Not at all. On the contrary, we want to encourage you to start the next part of our adventure - very demanding and completely new. We'll show you not Python itself, but a very specific kind of machinery (do not take this literally) which drives lots of contemporary computer systems, especially those which work on the Internet; moreover, which cannot work without the Internet.
REST isn't actually a word - it's an acronym. It comes from three words of equal importance:
- REpresentational
- State
- Transfer
Let's look at them separately.
Representational
RE stands for Representational. It means that our machinery stores, transmits and receives representations, while the term representation reflects the way in which data or states are retained inside the system and presented to the users (humans or computers).
REST uses a very curious way of representing its data - it's always text. Pure, plain text.
«It must be a joke,» you may think now. «How is it possible to send and receive all kinds of data using plain text?»
It's a very good question. Probably the best question that can be put now. REST is focused on a very specific kind of data - the data which reflects states.
We'll tell you more about this very shortly. Let's now make a jump to the next part of the acronym.
State
S stands for State. The word state is key to understanding what REST is and what it could be used for.
We think that your knowledge of classes and objects can be very helpful here. We want you to use it. Imagine any object. The object contains a set (the most preferable set is a non-empty one) of properties. We can say that the values of all the object's properties constitute its state. If any of the properties changes its value, this inevitably entails the effect of changing the whole object's state. Such a change is often called a transition.
Now imagine that the object is stored somewhere else, not on your computer, but on a server located over the hill and far away. Of course, you can access the server's resources using the network, but you can't just get the object and transfer it into your computer. Why not? Because it has to be accessible to many (maybe a few, maybe a million) users. It must stay on the server.
Imagine that you want to (or you must) affect the object's state through the network. No, you are not able to invoke any of its methods. Sorry, that's impossible. You can't do it directly. But you can do it using REST. How? We'll show you very soon. Let's now take a look at the last part of the acronym.
Transfer
T stands for Transfer. The network (not only the Internet) is able to act as a carrier allowing you to transmit states' representations to and from the server.
Note: not the object, but its states, or actions able to change the states, are subject to the transfer. We can say (it's a very poor analogy, but it will work here) that transferring the states enables you to achieve results similar to those caused by method invocations.
Representational State Transfer - We hope the term is less mysterious now. Don't be afraid - we won't leave you alone with your doubts. There is a long road ahead of us.
Let's start our journey from the very first step - from a story about how the network works and how it is possible to send and receive something through it. Not only states - literally anything. This is why we want to tell you about sockets. It's a very good place to hit the road.