REST is not a framework, it’s not a standard (like HTTP), it’s just a way that we came up with (a paradigm).
start off with modelling your data. everything is built around how your data is modelled
resources means the actual data
GET means i’m asking for something
POST means i’m trying to give you something
PUT means to update something
DELETE is self-explanatory
GET, POST, PUT, DELETE HTTP verbs= CREATE, READ, UPDATE, DESTROY (CRUD) operations
You can do this in JSON, determine what your actual resource looks like
1{
2 "name": "Simba",
3 "id": 1,
4 "age": 3,
5 "pride": "The Cool Cats",
6 "gender": "male"
7}
Next, design the routes to access your data, and CRUD operations based on HTTP verbs (because we are following REST)
Here’s an API blueprint in JSON. Some people define their API is YAML, or even Markdown. It breaks down all the CRUD operations you can do on one resource
1{
2 "GET /lions": {
3 "desc": "returns all lions",
4 "response": "200 application/json",
5 "data": [{}, {}, {}]
6 },
7
8 "GET /lions/:id": {
9 "desc": "returns one lion represented by its id",
10 "response": "200 application/json",
11 "data": {}
12 },
13
14 "POST /lions": {
15 "desc": "create and return a new lion using the posted object as lion",
16 "response": "201 application/json",
17 "data": {}
18 },
19
20 "PUT /lions/:id": {
21 "desc": "updates and returns the matching lion with the posted update object",
22 "response": "200 application/json",
23 "data": {}
24 },
25
26 "DELETE /lions/:id": {
27 "desc": "Deletes and returns the matching lion",
28 "response": "200 application/json",
29 "data": {}
30
31 }
32}
POST requests, we want it to send back the object we just created. Think of todos, when you create a todo, you expect to see the new item in the list. How’d you update your UI if the server never responded with the new todo?201 is the status code for successful creation