RESTful and HTTP APIs in Pyramid Transcripts
Chapter: What is REST?
Lecture: Comparing REST/HTTP services to other service types

Login or purchase this course to watch this video and the rest of the course contents.
0:01 Finally, let's compare how an http service works, some of the benefits and drawbacks of that,
0:07 to things like soap services, raw sockets, queuing and so on. So let's start with our topic of this course http services.
0:15 We've got our app, it's going to make a request over to our web server and this is just going to do a straight http get,
0:20 again some kind of uri, a noun, in this case a particular user with id 7 and the response is probably some kind of json, right,
0:29 here there's something with an id 7 and the name of it is Michael, here are your details. Ok, so what are the benefits and drawbacks?
0:38 Well the benefits, this is universally accessible, there is almost no more broadly spoken protocol than http,
0:44 so Python, Javascript, .net, C++ whatever you're doing, it can probably talk to this service.
0:51 Firewalls are all about letting the web out and blocking many other things, and so it's very firewall and http proxy friendly,
0:58 meaning it can get out of enterprise environments and things like that. It's cashable, right, this get is item potent,
1:05 theoretically it's cashable at the many layers throughout the whole request, at the proxy server, at the client, even on the server side.
1:13 You can look at it, it's understandable and humanly legible, right, you can easily read that response,
1:18 you don't need a lot of training to understand what that response means. Here's a person or user with a name Michael and id 7, done,
1:24 this is relatively lightweight, I'm thinking as opposed to like a soap service with an xml payload or something like that.
1:32 Now, there are drawbacks of course, it's not self describing, so just because you have an http service that has endpoints
1:40 it doesn't mean there's like a documentation page or on some of the protocols that actually generate client side things
1:47 that look like functions and you just treat it like it's a local thing, but it goes to the server right, we don't get that with http services
1:53 and if you're looking for the highest possible throughput it's not as fast as say binary data over raw sockets,
2:00 but among the services, this is a pretty lightweight protocol. So this is what we will be focused on pretty much for the rest of the class,
2:08 these types of services, but just so you can do sort of a compare and contrast and see the rest of the world what are the other options,
2:14 what else can you run into, let's look at a few other ways in which services get built.
2:19 Almost from the dawn of time we've had this concept of raw sockets you just open a socket bidirectional and you say you 001
2:27 and the service might say 1101 and you have to know what that means, right, a lot of times you'll say okay, well the first integer we're going to send
2:35 is going to be a operation code, and then if it's this operation the rest of the message is this shape, there's like two integers and a string
2:41 where the first value part actually describes the length of the string; now it's very custom and it's kind of a pain,
2:47 but it you can create the tightest, fastest possible operations because you are literally exchanging bytes like the way they are on the wire as bytes
2:57 and there's no extra overhead, right so there's no extra negotiation or encoding, decoding, serialization, deserialization it's just this, all right.
3:06 Now, there are benefits of course, it's very fast responsive like you can do basically minimal bandwidth,
3:12 you can even bitwise or stuff onto a single integer or single byte and then send that along, but there is a lot of drawbacks,
3:19 you have to come up with these protocols or if these are some platform specific ones like dcom or java rmi or .net remoting,
3:28 and that means in this platform specific cases, those can only talk to other java servers or clients, they can only talk to other dotnet or windows
3:38 or if you're doing distributed corba type stuff, this is not a very flexible protocol,
3:45 maybe no standards in the case where it's just truly raw sockets, it's far well unfriendly, it's hard to implement and it's definitely not legible,
3:53 but we do have that super high performance little latency low bandwidth thing and this is something people do do often.
4:01 The other major sort of cross platform service way of communicating was something called soap, simple object access protocol.
4:11 And this worked in some way like what you're familiar with, that would do actually http post to some url
4:17 and it would actually pass this action header to say this is what I'm trying to do, and instead of getting json back we get,
4:23 -- and we passed this thing called the soap envelope here, we've got you can see just a little bit of it, there is actually no data here
4:32 that's just like descriptive goo that wraps it, and then as a response we get a soap envelop back with the response in it,
4:39 so you can see this is quite heavy weight, but there are some advantages as we'll see.
4:45 It turns out that these services have a way to describe themselves, which is partly why they look so nasty in xml,
4:52 but the xml says here are the operations, these operations take these types they have these names and so on,
4:58 so because of that there's actually excellent tool support and certain things java and .net in particular
5:03 but even in Python there are some tools to work with these and they are easy to work with, provided you have the tools,
5:09 they are basically impossible to work with if you don't have the tools but they're not http rest services, and the reason is every operation is a post
5:18 even if it's reading it's a post, you're not using the verbs you are not using the content types, you are basically using the http transport layer
5:26 to move across this other protocol on top of it, right so http post only breaks this whole internet architecture
5:35 right, cashing for example is completely out the window as well as a bunch of other things.
5:41 Tooling is required, if you don't have the tooling to generate these little clients to talk to the stuff, it's way too complicated.
5:47 Another challenge is that these services are often built around functionality
5:51 so remote methods are usually the focus, log in, create user, things like that. It's also extremely bandwidth heavy and serialization heavy
6:01 and even though its words, it's not really legible as you see. Real quickly if we expand this out, like let's suppose
6:07 we want to call a function on a server called double an integer, it's going to take an int and return an int.
6:13 How much should we have to send back and forth for this to happen, not very much, but here's what it looks like in the simplest version of soap.
6:19 Let's send this, and see way, way, way down in the middle somewhere there's the 123 we're going to send, what do we get back for the response,
6:26 way there in the middle you see 426. So this is soap envelope exchange is something that happens on the internet,
6:34 it's much less popular now than it was five years ago, but if you work inside companies, there's still
6:40 a lot of enterprise systems doing this kind of stuff, the world is better with http services and things like that,
6:45 but you'll probably run into these, so you should know what they are. Finally, inside companies or in data centers, you will often see queuing
6:53 as a way for apps to communicate with each other, although this really almost never happens over the internet, it's still sort of possible, okay.
7:01 So maybe we have an app and it's going to say I'd like you to perform this operation so what it will do is it will post a message to this queue,
7:07 some time later, this other app is going to say hey there is a new message on the queue, give it to me I'll process it.
7:14 So this works really well, it could even be the same app by the way
7:18 with just some different functionality or whatever, pulling that back to process it. So why would we do this, right,
7:24 well, we don't use it very often for a direct communication but it does have some real benefits, it's highly scalable in a couple of ways,
7:30 suppose you have extreme peaks and valleys in the usage of your service for a moment it's really busy and then it kind of dies off for a while
7:38 and then it comes back; with standard services, you'd have to basically create a service that is capable of handling load at that peak,
7:46 whereas with queuing, you can kind of say I need a service that will handle the average, as long as it can keep up
7:51 or maybe if it can't, right, maybe in the evening it goes to sleep or you spend up another server, whatever.
7:56 The idea is you can put all that work under the queue and then pull it off best as fast as you can
8:01 and really long as you handle the average load you will be able to keep up, you can also have things like the server go down for a moment
8:06 wake back up and just backlog on the queue and it'll pick it up and go so you can handle intermittent processing and restarts and stuff like that.
8:14 But, it takes a special protocol, it doesn't really go through firewalls obviously it's not super easy to use across the different technologies
8:22 and there's no request response like login well what are you going to do, you're like I want to get this information about the user
8:29 okay well come back later, I'll tell you if I found it, right that's not a great experience.
8:33 But queuing is something people often use to create asynchronousy and independence between different parts of your app
8:40 and different scaling mechanisms at different parts of your architecture and so on. So these are interesting services as well,
8:45 but we are going to spend the rest of the class focusing purely on building http restful services.


Talk Python's Mastodon Michael Kennedy's Mastodon