Sterownik niestandardowy spoczynkowy Data Reszta z metodą łatki - jak połączyć zasoby z jednostką

Question

Domyślnie, gdy mamy repozytorium z odsłoniętą metodą składowania, możemy wykonać żądanie PATCH. Następnie REST danych Spring pobiera pierwotny obiekt z bazy danych i stosuje zmiany do encji, a następnie zapisuje je dla nas (w klasie JsonPatchHandler). Pozwala nam to zrobić następującą prośbę do klasy

class Address { 
    Long id; 
    String street; 
    Long houseNumber; 
} 

patch/api/adresy/1 z ciałem

{ houseNumber: 123 } 

i tylko tej jednej dziedzinie zostaną zmienione.

Teraz mający zwyczaj kontroler chcielibyśmy w sposobie aktualizacji odbierać cały obiekt (po hateoas połączyła go z oryginalnego obiektu z DB)

@RepositoryRestController 
@ExposesResourceFor(Address.class) 
@ResponseBody 
@RequestMapping("/addresses") 
public class AdddressController { 

    @PatchMapping("/{addressId}") 
    public Resource<Address> update(@RequestBody Resource<Address> addressResource, @PathVariable Long addressId) { 
     Address address= addressResource.getContent(); 
     // .... some logic 
     address = addressRepository.save(address); 
     return new Resource<>(address); 
    } 
} 

Niestety w miejscu, w którym chciałbym zrobić jakąś logikę Dostaję adres z pustymi polami zamiast połączonego obiektu.

Czy można podłączyć kontroler niestandardowy do stosu REST danych sprężynowych, aby podczas łatania żądania scalić go ze mną (tak jak ma to miejsce w przypadku normalnych repozytoriów)?

edit: chciałbym znaleźć rozwiązanie, które działa w sposób przejrzysty zarówno z patchem (typu zawartości: application/json-łata + json) i łata (Content-Type: application/Hal + json)

Answer 1

Po przejrzeniu źródeł wiosennych nie znalazłem rozsądnego rozwiązania. W wyniku I utworzeniu problem w ich - JIRA

Na razie jedynym rozsądnym obejście jest następujący - tworzyć niestandardowe kontroler, który ma PersitentEntityResource jako parametr i ma zarówno {ID} i {} repozytorium zastępcze na swojej drodze tj

@PatchMapping("/addresses/{id}/{repository}") 
public Resource<Address> update(PersistentEntityResource addressResource) { 
    ... 
} 

co sprawia, że ​​punkt końcowy inwokacja /adresy/123/adresy