Spring Boot Series - End Points Definition
3 minutes read
If you are new to this post, this is a continuation of the springboot-series where I am attempting to develop an food delivery app with Spring Boot. Do check it out here.
Web APIs are exposed through REST style over HTTP/HTTPS in our coding example.
Hypertext Transfer Protocol(HTTP) / Hypertext Transfer Protocol Secure(HTTPS) specifies verbs over which data is transferred between a client and server.
Hopefully if you are following up on my series you would have deduced by now that we are setting up an client-server architecture. The client and server can change independently but are bound a contract, as far as the contract is not violated the changes do not involve its counter part to under a similar change.
The verbs defines how the request needs to be framed to use the HTTProtocol. The various HTTP verbs are:
GET
POST
PUT
PATCH
DELETE
There are a lots of posts which define what each does so I am going to skip ahead of that. But what we will establishing here is what verb to be used for what kind of operation we would want to perform. Let’s take the CRUD operation and start assigning verbs for each.
I prefer to use,
HTTP Verb | Body ? | CRUD Operation |
---|---|---|
POST | Yes | Create a new resource in the server |
GET | No (can as per RFC document) | Read / retrieve a specific resource from the server |
PUT | Yes | Update ALL the properties of a resource with the data from the request body |
PATCH | Update SELECT property(s) of a resource with the data from request body | |
DELETE | Delete the resource from the server |
Now having established this mapping, lets talk about the elephant in the room.
PUT vs PATCH.
PUT and PATCH verbs seems to perform the same operation, update a resource. But a clear distinction is established in the implementation of the methods.
When using PUT all the properties of the resource is sent in the request body and ALL of it has to be replaced if the resource exists, else create the resource.
When using PATCH only the SPECIFIC property that is passed in the request body alone will be overwritten.
Let’s demonstrate this with an example,
## POST /user
Requet -> {"name":"Loreum","email":"loreum@ipsum.com"}
Response ->{"userID" : 1, "name":"Loreum","email":"loreum@ipsum.com"}
## GET /user/1
Response ->{"name":"Loreum","email":"loreum@ipsum.com"}
Now when using a PUT request your request would want to be
## PUT /user/1
Request -> {"name":"Ipsum","email":"loreum@ipsum.com"}
Response -> {"userID" : 1, "name":"Ipsum","email":"loreum@ipsum.com"}
Now when using a PATCH your request looks like,
## PATCH /user/1
Request -> {"name":"Ipsum"}
Response -> {"name":"Ipsum","email":"loreum@ipsum.com"}
When the email
property is missed out in the request body what should happen is the
## PUT /user/1
Request -> {"name":"Ipsum"}
Response -> {"name":"Ipsum"}
## GET /user/1
Response ->{"name":"Ipsum"}
If you had noticed this is what the server is supposed to respond when you PUT a request without the complete list of properties.
Since PATCH is a relatively new(2010!!??) to the race this specification is not handled by many of the libraries which provide them.
However, with Springboot this is something that has to be handled explicitly. Having established what HTTP verb we are going to each of the operation let’s move to the next step.
java springboot-series food-app springboot
21, Mar 2021