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
4:20
this is what I'm trying to do, and instead of getting json back we get -- and we passed this thing called the soap envelope here,
4:27
we've got you can see just a little bit of it, there is actually no data here that's just like descriptive goo that wraps it,
4:34
and then as a response we get a soap envelop back with the response in it, so you can see this is quite heavy weight,
4:42
but there are some advantages as we'll see. It turns out that these services have a way to describe themselves,
4:49
which is partly why they look so nasty in xml, but the xml says here are the operations, these operations take these types
4:56
they have these names and so on, 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.