This course has been updated! We now recommend you take the API Design in Node.js, v4 course.
Transcript from the "REST" Lesson
[00:00:00]
>> Scott Moss: So about REST? Well, Locke?
>> Speaker 2: Rest is the set of instructions, post, get, put.
>> Scott Moss: I'm gonna say this, whatever answer anybody says about REST, is probably gonna be right, cuz it's literally that blurry. Like, there is no good, definitely, so you are right. It is that.
[00:00:25] That's describing how REST works. It's very blurry, there isn't really a solid thing. There's no enforced interface. There's just like, some ideas around and, you implement them, and see how it goes. But tldr, it's the most popular API design pattern out there, I would say, but it's not this silver bullet, and also, like I said, it's very blurry.
[00:00:49] It's just some ideas that people came up with, and then, eventually, people just go off and just create their own different version of it that's completely different than what the idea started with. And I've never really truly seen of a strict REST API. I think the closest you might get to something like that, is like back in the day when you were generating APIs with Ruby on Rails, and they kinda just did everything for you, like that.
[00:01:13] But even then, you would denormalize and make something else, because your application needed something completely different, so it's very, very blurry. Like I said, it's an API design that combines database resources with route paths, and you said Lock, HTTP verbs. So it's a combination of those three things that allow the application to describe what action, as in a crud action, that they are trying to perform, right?
[00:01:38] So if I have resources, like a user and an account, and I wanna be able to perform crud on an account, the REST interface would allow me to perform those different actions based on the combinations of the route that I send to the server, and the verb, so it could be slash user with a delete.
[00:02:01] Now that API knows I want to delete a user, that type of thing. Any questions on that? Okay, so it was popularized when SAS products started offering APIs for integrations, basically. So all these SAS products started coming out, and when you're building an API for yourself internally, as in your web app is using your API, you don't really need to use REST, you can just do whatever you want, right, because it really depends on whatever your client needs, it'll be just very specific domain, like API.
[00:02:35] But would you open that API for developers to use, to integrate? Well, now you gotta have some type of standards and some type of form. You can't just be whatever you want. You can't be proprietary. So that's kind of where REST decided to show. It was created before that, but I think that's when it got popular, so.
[00:02:52] And then, obviously, Ruby on Rails made it super popular. Works with basic data models, and basically, what I mean by that, is it's really hard to scale with complex data models. So for instance, if you have like a graph DB, if you're the Facebook of the world, and all your data is linked with nodes and dependencies down here, that's a graph DB, the rest if really hard for that.
[00:03:12] Like it's really hard. It doesn't, it just doesn't really work for that. I mean, you'll basically just been extending what REST can do, and you might as well implement something else. So when I say basic data models, I mean, like basic, relational, hopefully, data models that don't really depend on each other, and yeah, that type of stuff.
[00:03:32] So, very hard.