12

I'm desiging a distributed application that will consist of REST services and a variety of clients (Silverlight, iOS, Windows Phone 7, etc). I was ready to decide that I would implement my REST services using WCF Data Services (OData) but now the the MVC 4 Web API has made me question that decision.

What I liked about OData was the URI querying and hypermedia capabilities you get for free. What I disliked was the verbosity of the OData payload; lots of unnecessary characters coming over the wire.

What I like about the Web API is that the payloads are much more concise and it has the URI querying capability of OData, however it seems to be lacking hypermedia (out of the box, at least). My boss is also pushing for the Web API because "the powers that be at Microsoft are backing it and OData hasn't been getting traction."

So I have two questions:

1) Can anyone comment on the backing/traction of the Web API and OData?

2) Is the Web API expected to natively support hypermedia by release time or are there any off-the-shelf implementations or examples I should look into?

Thanks!

Raymond Saltrelli
  • 1,344
  • 2
  • 12
  • 16
  • 2
    Good answers for question 1 so far. Anyone have any insight into my second question? – Raymond Saltrelli Mar 01 '12 at 17:51
  • Kinda missed that, and I've seen the term but I'm not sure what hypermedia is in a technical sense -- do you have a link? – Wyatt Barnett Mar 01 '12 at 19:00
  • 2
    Basically, hypermedia in the context of REST mean "lazy load". For example, if your request to a REST service returns an object that has a reference to another object, that references is represented as a link in the XML document as oppose to including the referenced object in it's entirety. If you want info about the referenced object, simply follow the link. http://dret.net/lectures/ppos-spring11/reading/wsrest2010-hypermedia.pdf – Raymond Saltrelli Mar 01 '12 at 19:09
  • 1
    Another good description of hypermedia with respect to REST. http://timelessrepo.com/haters-gonna-hateoas – Raymond Saltrelli Mar 01 '12 at 19:55

3 Answers3

2

Web API does odata. See Scott Guthrie's blog post. Specifically:

Query composition: Web API enables you to easily support querying via the OData URL conventions. When you return a type of IQueryable from your Web API, the framework will automatically provide OData query support over it – making it easy to implement paging and sorting.

I'd also think that in many cases the same class could be the traditional WCF class and the Web API class, they are definitely not mutually exclusive.

Wyatt Barnett
  • 20,685
  • 50
  • 69
2

Web API takes advantage of the http protocol more natively. Odata is an Open standard embraced by a lot of the big players. I can only speak from my experience int toying around with Odata, and recently discovering Web API and doing some research.

OData is cool because it's an actual standard. You can easily create a database and expose it over HTTP. This means you can traverse your table structure without any configuration (i say that loosely). You can also run queries through the URL which can include some light LINQ:

/products/orders/[put some linq-ish query here]

This is arguably good or bad. Authentication is standard and built it.

Web API, is more interesting from my perspective. It utilized the HTTP functionality (error messages, et al.) and is a bit more "native" to true RESTful requests. I really haven't played with it too much.. But i've read around and have kind of "heard" that MVC and Web API may be "married" some day, again, maybe good maybe bad...

When i was playing with OData, i created a Stored Proc, Mapped it into the entity surface, configured a strong return type and then hooked it up to a URL request and BANG, there's my RESTful request mapped to my typed result stored proc. It was fairly straightforward, and i was able to get exactly what i needed.

In Conclusion I haven't had a chance to play with WCF API in too much detail, but i would say it's the way to go for client development since it's more of a purist approach to REST. If you're going to be making more or less "straight" back and forth calls and retrieving "View Models", it will provide a more native interaction.

On the other hand. If you'll be making complex (ish) queries on the data based on the client interaction and you want to "build" the query logic and pass it as a parameter, then Odata could work.

The way i look at it is if i need to expose my data in a structural format (meaning table / relationship structure) and then query it directly form a client, then Odata will work best. It's also good for allowing "Others" to access the data (with proper auth etc..) which is why it adhere's to the OData protocol

If you want RESTful requests where you're dictating the URL (/products/orders/22, and creating complex "result sets" from your "hidden" managed code and data structure AND you might also benefit from the HTTP response messages, then the Web API would probably be the best bet..

again, this is all from research and toying. I haven't implemented either in a production / full blown app scenario. I think they'll both have their strengths and weaknesses, and there's definitely some overlap

hanzolo
  • 3,111
  • 19
  • 21
2

From the hypermedia point of view definitely Web API. OData, which is based on AtomPub, is just a way to expose a database using HTTP, you only get a limited set of predefined state transfers (CRUD). On the other hand, an hypermedia service is like an application, tailored for the client. With Web API you can embed all the links you want, plus you can also use the OData query syntax. Actually, the best hypermedia solution in the Microsoft stack is ASP.NET MVC, if you are willing to use HTML as base format.

Max Toro
  • 316
  • 1
  • 11