Okay, so we covered the most important part in the logic in JSON. We covered the generator, middleware configuration. So let's actually go ahead and start building the RESTful API. And we would cover the routes and all other nice things about request and response objects along the way. So first of all, let me tell you that it's possible to build two kinds of apps, or even maybe a third kind would be hybrid app.
The first category is traditional web apps, also called thick server. Think about late 1990s, early 2000. We didn't have any single page applications. Gmail wasn't there. So all we did was generate HTML on the server. Most of the logic, all of the logic in most of the cases, it was on the server. So obviously disadvantages. It was super slow and you could perform only single task.
Then you have to wait, and wait, and wait so forget about multitasking. Forget about like on a slack channel, you're sending a message and boom, you get a new messages. It's real time. So forget about all of that. You can do only one, single task and wait, wait, wait, wait for that to finish. Then obviously that's a very poor user experience. Poor and unresponsive UX.
On the desktop, we have very responsive, quick, snappy apps. On the web, it was slow. The speed was slow. The apps were slow. The whole architecture was slow. The whole approach was slow. And then also the application had to transmit a lot of bandwidth because the whole entire HTML page was replaced each time you would navigate and then if you're on the same website, the header is a footer most likely the inside of the page would remain the same, the menus, et cetera.
So this whole revolution of APIs led to the fact that we right now rarely build traditional apps anymore. Now we're moving towards micro-services, where each individual set of routes is deployed on different nodes and different machines. So what is REST? REST is basically, it's a RESTful Representational State Transfer and it's also the architecture that is keep things simple enough so you can exchange the data between different players. So before REST we had things like SOAP; it was a protocol, and then the URLs were structured differently.
Also REST really favors, it's really good with a stateless nature of the client-server architecture. Stateless means that it's not good to save the state of the application on one individual machine. If you don't save it on the individual server, then you can scale and have multiple servers for clients.
As the core of the RESTful API, we have a few HTTP methods, or verbs that we use for our CRUD operation, Create, Read, Update, and Delete. So it's GET, PUT, POST, and DELETE. Put, it's complete replacement, but in most of the cases we use it as a partial, so PATCH it's a partial, but most people don't use PATCH, and then we have HEAD and OPTIONS. They're mostly for course origin, research sharing. So what those HTTP methods mean?
They usually mean something similar along these lines. So GET /tickets will retrieve a list of tickets and then GET tickets/12 would retrieve a specific ticket. POST /tickets will create a new ticket. And then PUT /ticket/12 will update that ticket. So 12 is the idea of our ticket, and ticket is the resource. Then obviously to DELETE, we also need that ID. To PATCH, we also need ID. OPTIONS will give us the list of options, not surprisingly. And then the HEAD will give us the header.