Reputation: 2676
I've been messing around with Spring Data REST and it's good stuff. I like the HATEOAS integration and the ALPs. It is clear that it can solve many use cases by default or with little configuration.
My concerns are:
how to evolve it in case my business rules gets more complicated in the controllers?
Is there a way to overwrite default controllers to include specific code for a resource?
Upvotes: 2
Views: 320
Reputation: 83161
There's two aspects that might be interesting to solve the outlined challenges.
If all you want to do is intercept the CRUD operations backing the exposed resources you can implement a AbstractRepositoryEventListener
. It allows you to synchronously intercept the actions the Spring Data REST controllers impose on the entities. Use cases to be mentioned here can be additional validation, logging, filtering etc.
Another way to customize the functionality triggered by a request is through overriding a particular request mapping with a manually implemented controller. This can be used to augment the resources with new functionality (e.g. by exposing a new media type via the produces
attribute) or completely replace the functionality by simply declaring a matching request mapping on the controller methods.
Often times the standard resource model is not sufficient to express the domain logic or might just not fit. Users then usually craft their own controllers that they basically blend into the relation space of the resources exposed by Spring Data REST.
To integrate both worlds a ResourceProcessor
can be used to add links to the representation to point clients to the manually implemented functionality.
For an example of that, see the Spring RESTBucks project. The core lifecycle of an order is handled by Spring Data REST. However, a core state transition for the order is the triggering of a payment, which is implemented in a separate PaymentController
. The payment functionality is then advertised in the order resource using the PaymentOrderResourceProcessor
.
Upvotes: 4