Hi, Here we are going to show you a quick rundown on how to have a conforming RESTful API.

You can learn more about PATCH Method for HTTP here.

And as for the two different ways of sending data to your backend with HTTP PATCH method you can learn more by reading these two RFC docs:

1. JavaScript Object Notation (JSON) Patch.
2. JSON Merge Patch.

I also wanna add a link to body-parser. Here you can see that they are clearly stating it, they are assuming and parsing only requests with content-type of application/json. So that is why we had to do a bit more wok around it.

And lastly, but most important one too, my LinkedIn post for you to read more about them.

Please note that in this special example we did not need to take care of null since our reservation data model won't accept null. Meaning all the fields are required.

But I think it is relatively easy to figure it out how to remove fields on receiving null.

And here is my GitHub repo, lemme know if you have implemented it differently.

Coming from the future (2024.09.03)

1. I watched this YouTube video about designing RESTful API's and here in this video Jeffrey says that it is best when we are using JSON merge patch to implement PATCH, it should be idempotent.

2. Probably my implementation is not completely correct since in that same video that I linked above he outlines this scenario:

   1. Frontend sends a request to our PATCH /api/v1/users.
   2. Then it cannot receive a proper response from our backend.
   3. This time it retries the same request with the same body.
   4. Our backend should return a 200 HTTP status code. The reason behind it is that our backend just replaced the whole resource.

   As you can see it seems that we have only one PATCH method endpoint but I am wondering how they differentiate the existing documents from the new ones.

   I guess my implementation is complete since I check if there is a reservation with the same end, start and locationId for this user that is performing the request. So if it was the case I'll just replace it.

   Feel free to jump in and share your ideas too. I'm eager to learn how you guys think about this.

3. Learn more about REST here and here.

Coming from the future (2024.09.06)

1. I tried to make my reservation endpoints truly idempotent in NodeJS/NestJS. And I managed to do just that. But please bear in mind that everything comes at a price. You can see what I had to go through in order to make my PATCH /reservation/{reservationId} and DELETE /reservation/{reservationId} truly idempotent here.
2. Leave a comment on this topic, or better yet share your idempotent RESTful API written in NodeJS or any other language.
3. You could also not have a idempotent PATCH since the HTTP spec for PATCH states that it is not safe, neither idempotent. Although that does not mean it cannot be implemented idempotent at all. But keep in mind that out there there are other approaches and patterns to address the issue of creating a resource idempotently. It is called POST-PUT Creation pattern.
4. Regarding #3 I should also say that POST ain't idempotent as well. By definition it is meant to have some other side effects and it is won't purely create a resource of that type. So you might wanna learn more about that as well. But nonetheless you still need to have some sort of idempotency for even the POST HTTP method.
5. I read this Stackoverflow Q&A and already had entered into a discussion. Feel free to check that out as well.
6. The efforts that goes into testing an idempotent endpoint is also a bit more. So keep in mind that fact while reading the repo + integration tests written for that.