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