REST approach for a compute functionality and large number of input output parameters

[Mohit Sinha]

All - I have used the JAX-WS set of web services and familiar with the WSDL/SOAP approach for building solutions. Recently one of our clients asked for a REST based implementation after which i explored a bit on this topic.
However I did not get a clear understanding on few questions and how they are addressed in the REST world.

1) Can REST based approach for services be used for business logic operations or it is to be only used for CRUD actions?
2) One link mentioned REST can be used for business logic operations provided we use GET route and have only limited number of input and output parameters to pass from these business operation methods.

Hope someone can shed more light on this?


Regards,

[William Brogden]

1. oO course, why not? Actually REST is much more flexible than SOAP because the resource returned can be anything.
2. Consider the REST architecture.

Generally a GET returns a resource based on parameters supplied in the URL so you might run into problems with a large number of inputs creating a really long URL. All RESTful GET requests are expected to be Idempotent = not changing any resource on the server.

A POST would let you supply any number of inputs to your business logic. In any case, if your inputs change anything on the service, a POST is indicated.

Bill

[Mohit Sinha]

Thanks Bill that helps a lot.

One last question I had is how are REST based service contract details communicated to the calling parties. Are all REST (JAX-RS) implementations always based on a code-first approach?
I have always used a contract first (WSDL first) approach while developing JAX-WS services in the past and it worked great as we could convey the service definition details in advance and all calling client apps could kickstart their work simultaneously as we build out the service.

Based on my reading at various forums on the REST topic it seems contract first is not the ideal way to go about building services in the REST world though there is an less preferable option called WADL available. In this case I reckon technical documentation of the service interface is the only way to go without a tangible specification like WSDL.


Regards,

[William Brogden]

The RESTful web services like Amazon seem to rely on extensive documentation and example code in a variety of languages.

Although WADL was supposed to be the REST equivalent of WSDL it does not seem to have taken off.

As I see it, REST will never have a WSDL equivalent because REST is an architectural style while SOAP is a protocol - much more specific and thus amenable to a hard specification.

If anything comes first in a RESTful implementation, I would say it is definition of the resources to be served.

Bill

[Ivan Krizsan]

Hi!
One of the significant differences between SOAP web services and RESTful web services is that SOAP web services, if being in RPC style (versus document style), can have any number of "verbs".
RESTful web services, on the other hand, have a very limited set of "verbs", which operates on the resources of the service, typically implemented by the HTTP methods.
This is why people usually are under the impression that RESTful web services only can be used for CRUD actions.

You can use a contract-first approach with RESTful web services, but you will have to write the contract and design the way in which the contract is expressed yourself (if you do not want to use WADL), since there is no de-facto standard similar to WSDL for SOAP web services. I would recommend some design prior to implementation and some kind of documentation of the request and response messages, at least.
Best wishes!