2

We are creating an API that suits the benefits of a REST based architecture. However where I struggle is in how easy it is to consume from different technologies.

Its a c# WCF service and if consuming via c# is a doddle, 1) give the dll with the contract to the calling project 2) use the WebChannelFactory generic to wrap the contract before calling the url and method.

However given this is an API I want other non .net based systems to be able to interract with it. The argument I hear is that why should developers read all the documentation for the REST based service, manually create a http request (in their language of choice), and then parse the response. When if we created a web service using SOAP all they would have to do is add a reference to it and let their technology of coice build the call and response objects for dealing with the SOAP and make the call using a few lines of code (I know its this easy in c# and apparently java is easy too).

Seems like from a consumption perspective from differing technologies that support SOAP and building references from WSDL's that SOAP wins hands down. But I really want to use REST just have this argument and I cant really argue with it.

Exitos
  • 29,230
  • 38
  • 123
  • 178
  • 2
    Actually, consuming REST based services is very easy. Depending on the format or your return (in the case of WCF, JSON or XML) you can easily serialize the returns to proper object. I accomplished this in two lines of code on an iPhone using MonoTouch. If I were using Objective-C, it would be extremely easy as well. SOAP is much heavier and is more suited to an intranet environment. REST is much lighter from a bandwith and processing perspective. – Dave Ferguson Jun 17 '11 at 16:44
  • WSDLs can be used to describe RESTful services. Or so I hear, I've never actually seen them used that way. –  Jun 17 '11 at 16:45
  • Might help to read this [question](http://stackoverflow.com/questions/28950/guide-to-choosing-between-rest-vs-soap-services). – CoolBeans Jun 17 '11 at 16:55

5 Answers5

1

I also definitly recommend using SOAP for such a purpose. You already mentioned most of the benefits for SOAP against REST.

Why do you even really want to create a REST service if all facts point you to SOAP? For me REST only has the advantage of faster access, but in most use cases its not that much that it would justify not to use the advantages of SOAP.

BTW: If you create a normal .net WebService you get both "for free", because they support SOAP and REST by default (maybe you need to enable on ore another in the web.config).

Christoph Fink
  • 22,727
  • 9
  • 68
  • 113
1

I have only ever seen one argument for SOAP in favor of REST that I completely agree with, and your question makes it: Use SOAP if that is what the client/customer/user wants. If it really is the case that all of the consumers of this service can more easily use SOAP, then you should go with that.

Of course, if you want to support a client platform that does not have built-in support for SOAP, that could be another matter. You don't want your client/customer/user building a SOAP client layer from scratch, unless you just really don't like them.

dgvid
  • 26,293
  • 5
  • 40
  • 57
  • This is possibly the most sensible answer I have seen in along time on this forum in terms of the type of question im asking (no real right answer). You are right I have been struggling to realise that in order for the API to be successful it needs to be used. In order for it to be used it has to be easy to use. Ergo I should just use SOAP as thats what im currently being asked for. Alas I need to do some more research and find out what people really want at the moment its 1 nill to SOAP. – Exitos Jun 17 '11 at 17:27
0

The reverse argument is that SOAP only works on platforms that have a WSDL parser and SOAP stack in place. Without one it's completely impractical to ever use it, whereas REST can be boiled down to "send HTTP request, parse results as XML".

Yes, for certain types of APIs on platforms that support it SOAP will be easier to work with. And in other cases its not. :) It really depends on what you're trying to do.

In WCF it's not terribly hard to enable both, so it might be worth it to do that and let the people using your API choose what they want to work with.

Tridus
  • 5,021
  • 1
  • 19
  • 19
0

It sounds like what you're struggling with is that the industry is tending to move away from SOAP based services in favor of REST, but the tools for consuming such services are lagging.

One benefit of developing your service with WCF is that you abstract the endpoints (SOAP, REST, etc) from the actual application. Therefore, it seems premature to rule out SOAP or REST.

An approach might be to make your service by defining sound objects that you would like to expose for consumption. Once you've developed this, start trying to consume the service from different platforms/tools. You may learn that consuming a REST service is not as difficult as you might think. However, you may also learn that you simply do not need REST at the moment, but always have the option to turn it on if need be.

Scott Saad
  • 17,962
  • 11
  • 63
  • 84
0

From what you've described, REST is your best option.

Here's something to consider:

  1. There're several standards using SOAP, MS promotes WS-I Basic Profile 1.1 which is not so widely supported outside of MS world and people could easily have troubles connecting to your service.

  2. REST have many advantages over SOAP just by utilizing HTTP (testing, caching, etc.). Although if you need complex security or messaging, REST won't support this out-of-the-box.

  3. Using REST-services is really easy from anywhere, without any framework or tools.

Kostassoid
  • 1,870
  • 2
  • 20
  • 29