Search code examples
javaspring-bootrestpost

Understanding and Leveraging @PostMapping for Resource Updates in Spring REST APIs


I gone through experience developer spring boot code, he used @PostMapping for create, update, delete resource.

with some Id check logic he decide whether resource should be created or update!

Best practice and Considerations

  • What are the key factors to consider when deciding whether to use @PostMapping for updates, as opposed to the more conventional @PutMapping?
  • Are there specific scenarios where @PostMapping is particularly well-suited for updates?

As far as know about REST recommendation:

@GetMapping - getting resources

@PostMapping - Creating resources

@PutMapping - Update resources, if not available create it

@DeleteMapping - Deleting resources

@PatchMapping - Partial update

does making post request make API more secure to use for create, update and delete. OR is it good practice to use @Postmapping for secure API.

correct me if i am wrong.

here is some code sample:

@PostMapping("/createOrUpdate")
public ResponseEntity<UserDto> createResource(@RequestBody YourResourceType resource) {
 // use JPA findById to check it exist or not, and perform create or update logic
}
@PostMapping("/delete")
public ResponseEntity<String> createResource(@RequestBody YourResourceType resource) {
// use JPA findById to check it exist or not, and perform delete resource logic or 

Solution

  • as per my REST API knowledge, REST gave

    This isn't quite right.

    REST says: we should have a uniform interface. Which is to say, all resources should understand messages the same way.

    HTTP says: this is the way that HTTP should understand messages. That includes the semantics associated with each of the registered HTTP methods (GET, POST, PUT, and so on).

    POST is the method token with the least constrained semantics - we are correct to use it anytime the semantics of more specific methods aren't suitable (see Fielding 2009).

    Note that the HTTP methods of the transfer-of-documents-over-a-network domain - the methods describe the manipulation of resources (aka "documents"), and don't necessarily align with the useful work that occurs as a side effect of manipulating the documents.


    @PostMapping("/createOrUpdate")
    @PostMapping("/delete")
    

    Having a resource identifier for each kind of message is "fine"; it's essentially analogous to having a different resource for each form on a website.

    It's not necessarily an ideal resource model; using a distinct resource for each kind of message makes cache invalidation harder. But it will work, and it can be "good enough" in contexts where you don't actually care about caching.