@PatchMapping: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
 
Line 35: Line 35:
}
}
</syntaxhighlight>
</syntaxhighlight>
For possible problems related to [[@RequestBody]] and deserialization from JSON, see: {{Internal|Spring_REST_Concepts#Request_Body_and_Jackson_Deserialization|Request Body and Jackson Deserialization}}
==HTTP POST Semantics for REST Applications==
{{Internal|REST_and_Hypermedia#POST|HTTP POST Semantics for REST Applications}}


==Patching Semantics==
==Patching Semantics==

Latest revision as of 16:01, 27 March 2019

Internal

Overview

The annotation may also contain a sub-path relative to the class-level base path, usually configured with @RequestMapping.

REST

@RestController
@RequestMapping(path = "/a", produces = "application/json")
public class AController {

  @PatchMapping(path = "/{id}", consumes = "application/json")
  public ResponseEntity<A> patch(@PathVariable("id") Integer id, @RequestBody A a) {

    A current = content.get(id);

    if (current == null) {

       return new ResponseEntity<>(null, HttpStatus.NOT_FOUND);
   }

    if (a.getName() != null) {

        current.setName(a.getName());
    }

    ...
    return new ResponseEntity<>(current, HttpStatus.OK);
  }
}

For possible problems related to @RequestBody and deserialization from JSON, see:

Request Body and Jackson Deserialization

HTTP POST Semantics for REST Applications

HTTP POST Semantics for REST Applications

Patching Semantics

The above implementation has limitations: if null values are meant to specify change, how the client should indicate that a filed should be set to null. Also, collections can only be replaced in bulk, there is no way of adding or removing a subsets of items from a collection. TODO, more here.

HTTP PATCH Semantics for REST Applications

HTTP PATCH Semantics for REST Applications