Explain RESTful just like I'm five

Comments

[Adrian B.G.]

Wow, REST is a complex thing, hard to do examples from the physical world.

Your kinder garden has an "Open doors" day. You are chosen to have a stand and answer all the questions from visiting parents. You bulk some of the common questions in a couple of fliers.

You - the REST API
Kinder garden - the server/database
Parents - clients
Questions - web requests
Fliers - cached responses at your table (server memory) or the parents house - browser temp

I think this applies to most of the REST formal constraints:

Client-server architecture - you (the API) have the specific job to answer to parents (clients) questions (requests), with data from the kinder garden (server)

Statelessness - you do not remember (store) any context of the parent (client), you do not care what he did knew already or why does he ask the questions. (you do not keep it's states)

Cacheability - you can write down the answers to the most common questions and deliver the fliers if they ask 1 question from the flier.

Layered system - you can't tell and do not care if the question is asked by the parent who asked you, or is an intermediary for another parent. Security is a factor too (the parent who actually ask the question remains anonymous).

Cache on demand - the parents can keep their fliers at home, when they will return next year they will not just ask: are the fliers from last year still relevant? (302 not modified)

Uniform interface - all the kids have the same tables, look the same and answer the questions in the same way, as their teacher told them too.

[Ben Halpern]

I'll add that all of this is sort of imaginary and the reason the parents want you to adhere to these rules is because then they won't have to re-explain the rules every time. Divergence from the rules sometimes happens, because there's a lot of randomness human flaw involved in the coordination.

So if you're not sure why to use REST, because I said so is an okay answer. Uniformity is good, so you should have a really good reason for wanting to do things differently.

[DarkNada]

Thank u for describing me from the scratch 😇

[Adnan Kičin]

The most ELI5 explanation ever 😬

[Thyag Sundararmoorthy]

Look at the real world.

The real world has things (such as books and car)
Something can be done to these things (create, edit, delete)

The things are called "resources". Create, modify, and delete are called behaviors.

Through the 70's until early 2000s, we were building software functions in which things and behaviors were "coupled".For example, if you had to do something to a book named "da_vinci_code" you would do this:

• readBook "da_vinci_code"
• createBook "da_vinci_code" "some data"
• modifyBook "da_vinci_code" "some data"
• deleteBook "da_vinci_code"

The funtion name "readBook" can very well be named "scanBook". The function name "createBook" could have been named "instantiateBook".
This means, the developer needs to ADVERTISE/PUBLISH the name of each and every function. As a result, the documentation became huge and expensive to maintain.

REST is a way to neatly separate behaviours and things. Now you would actually do this :

• GET mywebsite.com/book/da_vince_code
• POST mywebsite.com/book/da_vince_code --newinfo --about --the --book
• PUT mywebsite.com/book/da_vince_code --updatedinfo --about --the --book
• DELETE mywebsite.com/book/da_vince_code

As you can see, there are only 4 popular behaviors (verbs) - GET, POST, PUT, DELETE
But the number of things (resources or nouns) can be infinite.
Note that things can be collections (book) and the thing itself ("da_vinci_code")

Thinking in terms of GET, POST, PUT, DELETE is simple and practical.

So REST is basically a way to design the interaction of things on the internet.