“This is the third day of my participation in the Gwen Challenge in November. Check out the details: The last Gwen Challenge in 2021.”
In Spring4.3, {@getmapping, @postmapping, @putmapping, @deletemapping, @patchmapping} are introduced to help simplify the mapping of commonly used HTTP methods and better express the semantics of annotated methods. As for @PatchMapping, it can be ignored for the time being. Patch mode is a supplement to PUT mode, which can be updated. However, the update is for the whole. Patch is for local update.
@requestMapping (value = “/get/{id}”, method = requestmethod.get) @requestMapping (value = “/get/{id}”) @ GetMapping (“/get / {id} “);
PostMapping: handles POST requests. Traditionally RequestMapping is used as above.
@putMapping: It’s almost the same as PostMapping, there’s no difference, you can pass parameters to Controller, but they are very different in nature, here I need to introduce a concept ———– idempotency: The definition in HTTP/1.1 is that one or more requests to a resource should have the same result for the resource itself (except for problems such as network timeouts). That is, any number of executions have the same effect on the resource itself as a single execution,
Here are a few key points to note:
Idempotent is not just one (or more) request that has no side effects on the resource (such as a query database operation that has no add, delete, and therefore no impact on the database).
Idempotent also means that the first request has side effects on the resource, but subsequent requests do not have side effects on the resource.
Idempotent focuses on the side effects of subsequent multiple requests on the resource, not the outcome.
Network timeouts are not idempotent.
Idempotence is a promise (rather than an implementation) of a system service that multiple external calls will have the same effect on the system as long as the call interface succeeds. Services declared idempotent assume that external invocation failures are the norm, and retries are inevitable after failures.
Taking SQL as an example, there are three scenarios, and only the third scenario requires developers to use other policies to ensure idempotency:
SELECT col1 FROM tab1 WHER where col2=2 UPDATE tab1 SET col1=1 WHERE col2=2; UPDATE tab1 SET col1=col1+1 WHERE col2=2;Copy the code
In simple terms, the result of multiple accesses to the REST service does not change.
HTTP specifies that PUT, GET, and DELETE requests are idempotent, while POST is non-idempotent. If an interface is defined as ACCESSIBLE by POST requests, the interface has a non-idempotent impact on the database. Therefore, when inserting new data, the post method is used, when updating the database, the PUT method is used, and so on. The @postmapping annotation marks the interface as a non-idempotent interface, and the @putMapping annotation marks the interface as a idempotent interface.
@deletemapping Deletes a URL mapping
@DeleteMapping(“candidateAssess/{id}”) public ResponseResult deleteCandidateAssess(@PathVariable String id) { candidateAssessService.deleteCandidateAssess(id); Return ResponseResult(” Delete successfully “, 200); }
As for rest services mentioned above, interested in their own can check, for REST services after consulting information, feel the most incisive explanation is:
If you look at the Url and you look at the HTTP method and you look at the HTTP status code and you know what’s going to happen