Did you use the same type of route to update patient information and to update an employee department?
Nope, to update a patient it is using the route:
http://..../patients/{id}
...and to update an employee department, this one:
http://..../doctors/{id}/department
and it happens to be like that because update patient's verb is PUT and update employee's verb is PATCH.
RESTful Resources Naming Convention help us, developers, to intuitively know what to look for and where to find it.
The main benefit of using the naming convention is that it helps to read or predict what source will get from an endpoint. On the other hand, if a developer is not familiar with the naming convention, using it can be quite confusing because in some cases the mapped routes are exactly the same.
@GetMapping("/doctors") @PostMapping("/doctors")
public List<Doctor> findAll() { @ResponseStatus(HttpStatus.CREATED)
return doctorService.findAll(); public void add(@RequestBody @Valid Doctor doctor) {
} doctorService.add(doctor);
The controller in this application maps the same url but they address to different services. This can be confusing for frontend developers since they are used to descriptive urls on the websites.
So, you'd better be familiar with RESTful if you want to work in big companies.
PUT allows to update the entire table on DB. PATCH a specific resource.
Imagine a streaming service or a huge online shopping website. They handle thousands, millions of resources here and there every second. Every bit counts in terms of efficiency. Now, imagine that a user of one of these platforms wants to change the profile name on the account. What would be more efficient? Replace all the profile information with a new one that is identical except for the profile name or patch only what is needed? Obviously, PATCH will be the winner here.
PUT instead, will be more efficient at the point that the whole pack of resources we need to change bypass other requirements.
Pure DTO-based services add a remarkable level of extra complexity and work to do, sometimes painful if we are figuring or maintaining a project with hundreds of entity objects and even more use cases.