.Net - Web Services

Soldato
Joined
5 Mar 2003
Posts
10,771
Location
Nottingham
Just looking for areas to research in this matter - what should I be looking for? There are web services (2.0 and prior), wcf services (3.0 onward) and then different variants on that (wcf-REST).
What are the web services weapons of choice these days? As long as it's .net I'll have pretty much free reign, but want to make sure the path we take is the future proof one as it's the foundation of what we'll be doing going forward.

Cheers.
 
If you want future proof and have free reign and want to do things right in general, then you will want a RESTful approach.

Problem is WCF REST is rather terrible. Though WCF Web API (open source project run by MS) improves it a lot.
 
If you want future proof and have free reign and want to do things right in general, then you will want a RESTful approach.

absolute garbage - REST and SOAP are complimentary web service technologies that serve different approaches

OP - you need to think about what you need - transaction support, reliable messaging, end-to-end secure communications? Then SOAP. Want Web 2.0 style features, ease of integration, support for non-SOAP clients and stacks? Then choose REST.

ASMX web services (.Net 2.0) are deprecated, you want to consider WCF as the baseline now.
 
SOAP is horrible. Why create an envelope within an envelope? :confused: (i.e. why create a SOAP envelope within an HTTP document..) It's on its way out, finally. So yes, future proof == REST.

WCF REST is still under development, it seems the Microsoft guys have been knocked over by its simplicity and just can't cope with it, unable to fathom that something so easy can do so much :p
 
SOAP isn't on it's way out at all - do you think REST supports advanced web service scenarios like those I listed above? No it doesn't, and it couldn't, by definition. For example, how can you guarantee end-to-end security for messages sent via REST over multiple intermediaries? You can't. Does REST support the WS-* standards and the protocols they define? No it doesn't.

SOAP and REST are technologies for different scenarios.
 
You need to learn more about REST if you think it can't do anything and everything that SOAP does. :)

WS-* doesn't support REST, because it is superfluous. REST, by its own definition replaces the need for WS-*.

Oh, and by the way.. REST is not a technology. REST is a paradigm.
 
absolute garbage - REST and SOAP are complimentary web service technologies that serve different approaches

OP - you need to think about what you need - transaction support, reliable messaging, end-to-end secure communications? Then SOAP. Want Web 2.0 style features, ease of integration, support for non-SOAP clients and stacks? Then choose REST.

ASMX web services (.Net 2.0) are deprecated, you want to consider WCF as the baseline now.

REST supports transactions, reliable messaging, and HTTPS. You just go about them in a different way. Sadly, at the moment it requires actual "thought" and "code". Whereas SOAP is more a case of just ticking some boxes on your IDE. Which is why so many mediocre developers are anti-REST.

REST is not a Web 2.0 technology at all. It's not even a technology. REST has, technically, been around since HTTP was first conceived. It's just that nobody back then thought to write up some documentation/thesis basically titled "Building applications on top of HTTP other than basic web servers and browsers". It's only recently that people have started to re-embrace HTTP because for over a decade it was in the gutter. REST is merely a design pattern based upon HTTP. As with all design patterns, 90% of it is up to the developer to get right based on his interpretation.

SOAP is a proprietary, unscalable, unversionable and high-coupling design. It is a form of RPC. It isn't a true web service.
 
Last edited:
REST1.png


REST2.png


http://www.infoq.com/news/2011/06/Is-REST-Successful
 
i say again - SOAP and REST are technologies for different scenarios. SOAP will be around for a long, long time.

The OP needs to consider what they want depending on the problem they are looking at. I'd hate to have to apply "thought" and "code" manually in order to implement some of the advanced features in a REST service that SOAP provides out of the box.

Remember that the OP is using WCF. The WCF REST stack is immature at the moment, as are many others.
 
This is like asking whether chicken breasts or frying pans are better.

SOAP is an XML encapsulation that is usually transferred over HTTP, it's not proprietary. REST is just an architectural design that uses HTTP as the transfer mechanism.
 
As to the original question, I have no idea. Just squirt request/responses over HTTP, not that complicated.
 
This is like asking whether chicken breasts or frying pans are better.
I don't think it is. The OP asked what web service technology to use considering he has free reign and that it must be future proofed.

There is only one answer to the criteria given in this question. REST. End of thread.

Not saying it is easy. REST requires much more thought and code than the typical SOAP stack at the moment. But "doing things right" is rarely the easiest option. You have to work for it. Mediocre developers tend to opt for SOAP, and will continue to do so for years, because the complexity is much lower and most IDE's nowadays make it very much "3 clicks" affair... Nobody is denying that. Doesn't mean every developer wants to go for the easy (but least maintainable) option.
 
Last edited:
Out of interest can you provide some material about REST being used for processing of data rather than the typical resource-centric services?

For example, a REST service that takes a number of observations as inputs and runs them through some form of model resulting in a number of outputs. I can see how this works with a SOAP service but don't have much experience with REST services.

Thanks.
 
Out of interest can you provide some material about REST being used for processing of data rather than the typical resource-centric services?

For example, a REST service that takes a number of observations as inputs and runs them through some form of model resulting in a number of outputs. I can see how this works with a SOAP service but don't have much experience with REST services.

Thanks.

REST is a communication link basically, it's just a mechanism to request atomic actions against a remote service using a request/response paradigm. It's RMI over HTTP. Things like SOAP build (generally) on top of REST.
 
SOAP is RPC for a start, it couldn't be further from REST if you tried :p REST is not just a communication link at all. It is a paradigm of data communication. It's much, much more accurate to compare (and spot the many differences!) RPC to REST than it is to compare SOAP (an implementation of RPC) to REST.
 
Last edited:
Back
Top Bottom