What Is REST?
00:22 Fielding defined the REST protocol based on the HTTP standard at the time, making it something that could be implemented without making changes to the network. Anyone who could run a web server could run the REST protocol.
01:10 HTTP is already this way. In fact, cookies were created inside of the HTTP protocol to get around this fact. The third constraint is cacheability. The protocol needs to be able to support caching on the client side. Once again, this maps very nicely to web servers.
01:28 Web servers already introduce cache headers to indicate whether or not data has changed on the server side. The system must be layered. This means that things like proxies and load balancers could be between the client and the server and should not affect the client or the calls.
02:27 The data is self-contained. This is usually implemented through the use of URLs, so the data corresponds to a URL and you can use that URL to do things like change the data or delete the data on the server side. The data is intended to be self descriptive.
02:44 If there’s information that is needed about the encoding of the message, it is included in the message. This is similar to the accepted types header inside of HTTP, which indicates what kind of encoding the client supports. And finally, the rather dubious acronym, HATEOAS—Hypermedia As The Engine Of Application State.
03:36 “The code is more what you’d call ‘guidelines’ than actual rules.” I really probably should have done that in my best pirate voice, “Ar.” In practice, what this means is every implementation is a little bit different.
Oftentimes, only a subset of REST is implemented. When I first started writing REST interfaces, I very seldom implemented the entire protocol. Frequently, I was just doing XML over HTTP, using
GET to get the data, which is REST-like, but not bothering with all the puts and patches and other things. For example, using
POST to make changes, which isn’t quite REST-compliant.
04:16 This lack of adherence to a standard sounds like it might be a problem. How are you going to know what to do? Because the protocol is based on top of HTTP, you don’t need any fancy libraries in order to access it.
Any library that supports HTTP supports the use of REST. As a result, client-specific code ends up being just that—client-specific code. So whether or not the implementer used
POST correctly isn’t going to matter very much because you’re going to have to look up the API’s documentation as to how to talk to it anyways.
04:57 The good news about this is it makes REST far more lightweight than similar technologies that are all-encompassing, like SOAP. The bad news about this is sometimes you have to pay a little more attention to the documentation to know how you’re going to use it.
You can get away with this being so ill-defined because REST is built on top of well-known standards like HTTP. If you’ve done any web programming, you’re probably already familiar with the idea of HTTP
POST. REST uses these as well as other HTTP methods.
POST is used to create a resource. In the web world,
POST is used for submitting forms. The body of the
POST contains the fields of the form. In the REST world, the
POST is used to create a new object.
Those same fields are used to specify the fields of the object that’s being created. The URL that you’re posting to specifies what object is being created.
PUT is somewhat like
POST. It uses the fields to specify information about the object, but in this case it’s to update the object.
PATCH also is used to update the object.
Let me run you through some examples. Here’s a URL that if you call the
GET method on will retrieve a list of books. Further refining the URL to specify an ID and doing a
GET will not get all of the books, but a specific book—in this case, the book with
POST, you specify fields—the
title and the
author. In this example, the title is the same as that which was created in the previous one, but the author has been changed. Because it’s a
PUT, I have to specify all of the fields.
The author will stay Franz Kafka and the title will change from Metamorphosis to The Metamorphosis. And finally, here’s a
DELETE. Similar to a
GET, it specifies a URL that fully qualifies the book. In this case, I’m deleting book number
08:22 The REST protocol does not specify the format of the payload. The most common payloads are JSON and XML. The DRF, which the rest of this course is about, supports these out of the box, and there are third-party packages that you can use to add onto the DRF to support other ones as well. A popular one adds YAML as a payload.
curl from showing the progress information. The URL that I’m hitting is the
localhost on port
8000—for example, on my own little Django server—and the path I’m hitting in the URL is
books/, because I want a list of books.
09:10 Normally what comes back from the server is an undifferentiated JSON blob. That tends to be hard to read because it’s all in the same line, so I’m going to augment this command with a pretty printer.
Become a Member to join the conversation.