feedback on Service layer contract limitation

[rhodebump]

Hello,
Just wanted to say that this is an awesome plugin! I appreciate all the hard work that went into its creation and documentation. I am using it successfully for the CRUD operations that I want to expose as rest services.

However, I now need to expose non-CRUD services as REST services. For example, I would like to create a registration service (to allow users to register for the website). There are a lot of operations such as the aforementioned that can not meet the ResfulServiceAdapter contract.

While I am not expecting an answer (or anything) from you, I am certain that other users are trying to solve the same problems. I am going to research how to do this now, but it would be nice to include as note about how you would accomplish the goal of exposing a service that doesn't fit into the contract.

Thanks again!

[sriddell]

Thanks for the feedback. Sorry for the late response; I've been away on vacation for much of Dec.

The service adapter contract was modeled after the basic REST operations; you can inject your own adapters, but you do end needing to operate within the constraints REST itself imposes (basically, performing create/update/list/show/delete operations against resources).

Do you have some examples of where you are having trouble making things fit? I suspect it may be similar to issues I encountered myself and had to step back and re-think how to do things to make them amenable to a resource-oriented/RESTful design in some cases.

[rhodebump]

Thanks for getting back to me.

After I read the following two links, I decided that I needed to change my
way of thinking, and that your plugin in perfect! I have created some
services that the list/count are not really applicable, but I just return
empty lists for these methods.

http://stackoverflow.com/questions/2001773/understanding-rest-verbs-error-codes-and-authentication
http://stackoverflow.com/questions/2687892/what-to-do-when-you-need-more-verbs-in-rest?lq=1

On Wed, Jan 7, 2015 at 1:14 PM, sriddell [email protected] wrote:

Thanks for the feedback. Sorry for the late response; I've been away on
vacation for much of Dec.

The service adapter contract was modeled after the basic REST operations;
you can inject your own adapters, but you do end needing to operate within
the constraints REST itself imposes (basically, performing
create/update/list/show/delete operations against resources).

Do you have some examples of where you are having trouble making things
fit? I suspect it may be similar to issues encountered myself and had to
step back and re-think how to do things to make them amenable to a
resource-oriented/RESTful design in some cases.

—
Reply to this email directly or view it on GitHub
#23 (comment)
.

[sriddell]

Glad it's working for you. If you have resources that only support a subset of the methods, you can also specify this in the DSL; the plugin will return a 405 with an Allow header specifying the methods supported by the resource if an unsupported request is made. See 'Limiting methods for a Resource' in the README for the details.