Coffeehouse Thread

35 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

A first-class REST framework for .NET

Back to Forum: Coffeehouse
  • User profile image
    W3bbo

    I've been working on a RESTful project lately, using WCF as the framework because... well... Microsoft wants people to believe it's the best solution for every web-service task out there. However I've discovered that WCF is really quite inflexible, even with all the extensibility points it's still a very difficult beast to tame.
    For example, none of the default data serialisation techniques (DCS, XS, JsonS) give you all that much control over what output is sent to the client, or how to deserialize input in the request. Another issue is the "integration" with ASP.NET, especially under IIS. Ideally you'd expect WCF to be totally separate from ASP.NET, and let it handle its own configuration, authentication, and authorisation. This is true under self-hosted scenarios, but not under IIS where the majority of WCF services are deployed. Then, of course, there's the issue of how WCF is still ostensibly designed around RPC, with stateless REST tacked on in the point release, so it will never "feel" right. So I was thinking that it wouldn't be too hard to build a well-designed framework solely for RESTful development, that did everything by itself, including service hosting (I.e. In it's own daemon process, free of any complexity added by IIS and ASP.NET). If you want to run it on port 80 on the same machine as IIS then just use http.sys for multiplexing. Any thoughts?

  • User profile image
    W3bbo

    Apologies for the walloftext, channel 9 doenst format text on the iPad, and when I tried to insert manual HTML formtting I got an error message.

  • User profile image
    blowdart

    Have you looked at the WCF REST rewrite that's going on right now? They're pretty open to feedback too.

  • User profile image
    vesuvius

    @W3bbo:I think there are significant issues with the REST stack as it has been called several different names in under two years, Glen Block was up here in Edinburgh a few months back getting feedback from some developers here.

    For owt' to do with authentication, SOAP/SSL is the best way to go, because it just isn't what representation state transfer is meant to be dealing with.

  • User profile image
    Lee_Dale

    When you say it doesn't give you that much control over output what do you mean?

    I have built WCF applications using the rest services that return pure XML and I can output any XML I want or I could just send back plain text or JSON etc. 

  • User profile image
    W3bbo

    ,leeappdalec​om wrote

    When you say it doesn't give you that much control over output what do you mean?

    I have built WCF applications using the rest services that return pure XML and I can output any XML I want or I could just send back plain text or JSON etc. 

    Suppose I want to return this to a client in the response body:

    <accounts pageSize="5" pageIndex="2" totalCount="364">
    <account>
    <id>1</id>
    <moreelements></moreelements>
    </account>
    <account>
    <!-- more stuff -->
    </account>
    </accounts>

    When using declarative attributes (either DCS or XS) you really don't get much control over what's generated, so you could say to use IXmlSerializable, however when using this I see that it already writes out <accounts>, which means you can't put in any attributes.

    Unless you know a way around this?

  • User profile image
    Lee_Dale

    So what your really saying is that the automatic XML serializers in .Net are the issue not WCF.  

    For instance I could build up the XML manually and return a XMLElement.  This is what I had to do for my service.  Using these attributes:

    ResponseFormat = WebMessageFormat.Xml,
    BodyStyle = WebMessageBodyStyle.Bare

    Obviously it's more work than getting automatically serialized objects but it's still doable.

  • User profile image
    W3bbo

    ,leeappdalec​om wrote

    So what your really saying is that the automatic XML serializers in .Net are the issue not WCF.  

    For instance I could build up the XML manually and return a XMLElement.  This is what I had to do for my service.  Using these attributes:

    ResponseFormat = WebMessageFormat.Xml,
    BodyStyle = WebMessageBodyStyle.Bare

    Obviously it's more work than getting automatically serialized objects but it's still doable.

    Well, one of WCF's selling points is the pervasive use of .NET's serialization, so I'm a bit miffed how I have to do things manually.

    Can you post some basic prototype/skeleton code how to do what you do?

  • User profile image
    Lee_Dale

    Well in my application I needed to return the data in 3 different formats.

    One was the default .Net serialization XML, the second was JSON, the third was custom XML. 

    One client of the service was a standard HTML JS application where the devs didn't know .Net so I chose REST services so I could use a simple address based API but allow querystring parameters to control which format is returned.

    WCF REST gave me the ability to use the same URL string i.e. /Posts /Topics etc but by appending ?format=JSON or ?format=XML I was able to service different clients.

    The power of WCF here was that I could use different contract methods mapped to the same URL.

    So for my custom XML methods I basically used the same domain objects but had a XML conversion layer that used XmlDocument to build up my custom xml then I just returned this document as a XmlElement. 

    [OperationContract]
            [
                WebInvoke(Method = "GET",
                            ResponseFormat = WebMessageFormat.Xml,
                            BodyStyle = WebMessageBodyStyle.Bare,
                            UriTemplate = "Topic/{topicName}")
    ]
    XmlElement GetTopics(string topicName);
    
    

  • User profile image
    W3bbo

    Interesting. I see you're on Skype right now, can we have a quick chat about this?

  • User profile image
    Maddus Mattus

    ASP.Net MVC is my framework of choice for REST services,..

    WCF is just to complicated for REST,..

    If you want a quick datalayer you can use WCF Data Services, but that comes with a big bloat,..

  • User profile image
    cbae

    ,Maddus Mattus wrote

    ASP.Net MVC is my framework of choice for REST services,..

    WCF is just to complicated for REST,..

    If you want a quick datalayer you can use WCF Data Services, but that comes with a big bloat,..

    WCF Web API integrates well with MVC3.

     

  • User profile image
    PerfectPhase

    @blowdart:  I would also recommend taking a look at the new WCF Web API (wcf.codeplex.com, not the WCF REST starter kit), should address most of the issues you mentioned.

    Also, and I know this isn't WCF, but have you had a look at things like OpenRASTA?

  • User profile image
    Maddus Mattus

    @cbae: looking into it right now,.

    reading; http://blogs.msdn.com/b/endpoint/archive/2010/11/01/wcf-web-apis-http-your-way.aspx

    first impressions; seems like a big hassle to me

    asp.net mvc is just; register route, write controller, return xml, json or html,..

    that to me, is first class,.

  • User profile image
    Bass

    We use Spring MVC to write web services, I assume using ASP.NET MVC would be a similar approach. Writing the controllers are really easy and you have the maximum control on how your REST API will look.

    If you want to abstract REST from your app, you can have a "service layer" that sits in your model. I think you could easily use a service that was originally designed for use with WCF in this manner as well.

  • User profile image
    W3bbo

    ,PerfectPhase wrote

    Also, and I know this isn't WCF, but have you had a look at things like OpenRASTA?

    I had a look at OpenRASTA, but I'm not comfortable with it. Their "fluent" coding style makes me twitch, and I'm concerned about feature-creep.

  • User profile image
    cbae

    ,Maddus Mattus wrote

    @cbae: looking into it right now,.

    reading; http://blogs.msdn.com/b/endpoint/archive/2010/11/01/wcf-web-apis-http-your-way.aspx

    first impressions; seems like a big hassle to me

    asp.net mvc is just; register route, write controller, return xml, json or html,..

    that to me, is first class,.

    And that's exactly how the WCF Web API works. You register the routes that you want to call your web service resources, and the remaining routes just go to the MVC controllers. The framework takes care of all the "plumbing" for you. That blog post just shows you how to "reroute the pipes", if you want to. But you don't have to.

    http://wcf.codeplex.com/wikipage?title=Getting%20started:%20Building%20a%20simple%20web%20api

  • User profile image
    Maddus Mattus

    @cbae: I do that now without the API, just use the DataServiceHostFactory and the routing framework,.

    But I think I am not getting my point across,..

    For a first class REST framework, ideally you dont want separate API's for different formats. That's where ASP.Net MVC comes in. It can serve out HTML, JSON or XML depending of the HTTP request headers.

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.