Let me explain better…
Currently we need to define several service methods if we want to deal with custom CRUD scenario (not enabled by default via entities endpoint, for a variety of business reasons).
This goes against REST principles… resources should be accessed using standard HTTP methods, but now we are stuck with calls like:
while we should have instead:
services/someservice/something (GET with standard id query param and others) OR services/someservice/something/id that is equivalent to id= query string
services/someservice/something (PUT with id in query string or payload), OR services/someservice/something/id (ignoring id in payload)
services/someservice/something (DELETE with id in query string) OR services/someservice/something/id
dealing with this is not such a big deal if we refactor the ServicesController class to support dynamic method invocation, using a convention based lookup from rest-services.xml file, like so:
for POST on “something”, search for a “createSomething” method with single parameter (body)
for GET on “something”, search for a “getSomething” method and pass query strings to parameters
for PUT on “something”, search for a “updateSomething” and pass the id alongside payload, or if not found fall back to “createSomething” (for example, this should be considered carefully)
for DELETE on “something”, search for a “deleteSomething” and pass the id
Please note that this is not a duplicated “entities” functionality, it is a smart way to let developers build their own “canned down” or “enhanced entities” specifically for their specialized REST clients, that most of the time have different requirements/constraints than standard (vaadin) client.