Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm building an ajax heavy application (client-side strictly html/css/js) which will be getting all the data and using server business logic via webservices.

I know REST seems to be the hot topic but I can't find any good arguments. The main argument seems to be its "light-weight".

My impression so far is that wsdl/soap based services are more expressive and allow for more a more complex transfer of data. It appears that soap would be more useful in the application I'm building where the only code consuming the services will be the js downloaded in the client browser.

REST on the other hand seems to have a smaller entry barrier and so can be more useful for services like twitter in allowing other developers to consume these services easily. Also, REST seems to Te better suited for simple data transfers.

So in summary SOAP is useful for complex data transfer and REST is useful in simple data transfer.

I'm currently under the impression that using SOAP would be best due to the complexity of the messages but perhaps there's other factors. What are your thoughts on the pros/cons of soap/rest for a heavy ajax web app?

EDIT:

While the wsdl is in xml, the data I'm transferring back and forth is actually in JSON. It just appears more natural to use wsdl/soap here due to the nature of the app. The verbs GET and POST may not be enough. I may want to say something like: processQueue, or executeTimer. This is why my conclusion has been wsdl/soap would be good for bridging a complex layer between two applications (client and server) whereas REST would be better (due to its simplicity) for allowing many developer-users to consume resources programmatically.

So you could say the choice falls along two lines

  • Will the app be verb-oriented (completing tasks: use soap) or noun-oriented (consuming resources: use REST)
  • Will the api be consumed by few developers or many developers (REST is strong for many developers)?

Since such an ajax heavy app would potentially use many verbs and would only be used by the client developer it appears soap/wsdl would be the best fit.

share|improve this question

2 Answers 2

If you are doing an AJAX heavy application then one pro about REST is you have the option of using JSON as your data-interchange format instead of XML. JSON requires less markup than XML so that would speed up your application since you would be sending less data over the wire.

It also seems that REST is over taking SOAP with web services, and its always a good thing to use a technology that is more widespread when you bring on new developers or if you want other developers to consume your data.

The pro for SOAP is that it already has structure built into it, but I don't see why you can't build your own structure into your REST solution.

EDIT: When I did telecom programming our phone switch only supported SOAP and not REST. I found that SOAP required a bunch of boilerplate stuff that just got in my way when I didn't need it.

share|improve this answer
    
While wsdl is in xml the information passed back and forth is actually in JSON. I'll add more info in the question. The pro you mention for SOAP is why i'm leaning the soap way. It appears easier to maintain as the verbs I build can be more expressive. Thanks! –  coder Jun 24 '12 at 12:57

SOAP and REST are not the only options. There is another called Direct Web Remoting.

Check it out.

SOAP requires mashalling/serializing. REST requires adherence to GET POST paradigm, often times, neither of these are necessary for a straightforward transmission of data from client to server.

This is the notion of Direct Remoting. The POJO (plain old Java Object) that exists on the server, exists on the client. The methods that are defined to be visible are called by the client and the return type is essentially the AJAX callback.

Hope that helps. All the best! Nash

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.