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
@PostMapping
for updates, as opposed to the more conventional @PutMapping
?@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
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.