The Jason Salas Experience

Guam's Mr. Media - making people think, making people laugh, pissing people off

Friday, December 30, 2005

No REST for the ambitious

One thing I've been thinking about lately is why Microsoft doesn't tout REST support in .NET, or if such is even applicable. When I picked up the .NET model for web services development, it was always about SOAP, starting with the Microsoft SOAP Toolkit and moving on through ASMX files. The default response is HTTP-SOAP, but you can also make services callable through HTTP-POST and/or HTTP-GET.

This led me to question whether the latter two protocols were actually REST in disguise, being another instance of Microsoft's insistence to not use industry terminologies.

Sam Ruby explains:
Just because a service is using HTTP GET, doesn't mean that it is REST. If you are encoding parameters on the URL, you are probably making an RPC request of a service, not retrieving the representation of a resource.
So if this isn't the case, are .NET web services capable of supporting REST? Or is this only a client-side concern for consumers?

posted by Jason Salas @ 10:10 AM  

4 Comments:

  • At December 30, 2005 1:05 PM, Blogger Mark said…

    Actually, Sam's wrong in that quote; ignoring what's in the URI, if you can invoke GET on it and receive data, then that's REST.

    I don't know enough about .NET, but I have looked over System.Net and System.Web, and they look fine for Web/REST development. The WCF stuff is another story altogether though; a real mess, from my POV. Clemens Vasters is thinking about what it would mean to add HTTP/URI support to it, which is great, but what he describes has some big problems and doesn't leverage what we already know about what constitutes a decent Web framework.

     

  • At December 30, 2005 2:12 PM, Blogger Jason Salas said…

    Hey Mark,

    Thanks for the comments! I'm starting to see more and more REST development for web services and SOA, and less SOAP endorsement. I even found a post (no URL, sorry) that mentioned that SOAP's no longer an acronym...just a generic name for a specific type of RPC.

     

  • At December 31, 2005 2:14 AM, Anonymous jonah said…

    ... "So if this isn't the case, are .NET web services capable of supporting REST? Or is this only a client-side concern for consumers?"

    I think the question isn't wether .NET webservices can support REST but instead can .NET support both "types" of webservice implementations - the answer to that is yes.. the same is true for any platform that supports HTTP POST/GET/PUT/DELETE. REST is an alternative way to implement a service via the web, although more simplistic in nature than RPC (SOAP). Because of this, the ability to perform the same HTTP actions (POST, GET, PUT and DELETE) is the only requirement necessary for a client to integrate with a REST based webservice implementation. A disadvantage is that it is less sophisticated - one example is that an RPC implentation allows you define a webservice with webmethods that return user defined objects - obviously this is not the case for REST. So client side integration is more natural using RPC from a programming perspective - you're essentially dealing with an exposed API just like another class in your library - and at least in the .Net client to .Net webservice scenario.. the overhead associated with implenting details related to SOAP is automatically generated for you.

    btw also in agreement with mark - "Actually, Sam's wrong in that quote; ignoring what's in the URI, if you can invoke GET on it and receive data, then that's REST."

     

  • At December 31, 2005 6:59 AM, Blogger Jason Salas said…

    Hi Jonah,

    Thanks for your thoughts! I had a feeling it was possible, In the more than 90 books I've read on .NET web service development, I don't think REST has ever been mentioned, although when you venture out into open source waters you'll pick it up immediately along with the whole REST vs. SOAP debate.

    It's like JSON...next to no one in Microsoft development circles heard about it until AJAX hit the scene with Atlas, now people are talking. (But many MS developers still won't be able to tell you what JSON is.

     

Post a Comment

Links to this post:

Create a Link

<< Home