Has anyone used the new WCF REST Starter Kit successfully and would you use it again?

Question

As the title suggests, I would like to see if this is something people are happy with.

I have several projects, where I will dedicate some time in experimenting with different kinds of technologies web service related, preferably alternatives to SOAP which would be well integrated inside/with dotnet.

I would like to hear if there are already some success stories or people's opinions on the worthiness of the starter kit:

Is the kit still too fresh for people to have been taking it on well enough to be proud of what they accomplished with it?

Some background:

I have team members who are new to both SOAP and REST, and I am balancing which one to motivate them/myself on.

.

I personally am not too enthusiastic about SOAP, but just like my aversion to SQL I blame my own lack of experience on the subject more than on the technology itself.

So in looking for some other way to handle web related servicing, I bumped into REST and so far so good.. how is this being received by the community?

I would be happy to see comments and people's recommendations on alternatives to the starter kit.

Going a bit beyond the original question, comments on REST as a whole for distributed hypermedia in replacement of SOAP and from people who would like to defend SOAP are also welcomed.

Sorry if this is a dupe, I did look around and didn't find anything quite like what I would like to know.

Thanks,

Ric

Answer 1

I spent about two weeks prototyping a RESTful service using WCF with the REST starter kit, and found that it was extremely difficult to get to grips with, incredibly unintuitive, and made a lot of things that should be simple really quite difficult. It really feels like they're trying to bolt an HTTP emulation layer on top of a layer that's designed to abstract away HTTP and it's messy as a result.

For reference, the prototype included implementing CRUD functionality, the X-HTTP-Method-Override header, custom translation of any errors into a standard error block, support for both XML and JSON as both input and output formats, authentication and authorization of the caller, and dependency injection of any internal services into the outward-facing services.

I then spent a week or so prototyping the same API using ASP.NET MVC and found it much simpler to get to grips with, intuitive to extend, and nothing in the above list was difficult (I was stumped on the header for a while, but the solution turned out to only be 10 lines of code or so). ASP.NET MVC is fairly close to the underlying HTTP protocol and as such makes it easy to implement a RESTful API which embraces it.

So my personal recommendation (and the one my company has gone with on the basis of my research) is to steer well clear of WCF for RESTful services and go with ASP.NET MVC.