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
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.
I'd suggest having a look at OpenRasta, which is much closer to http semantics than asp.net MVC is. http://trac.caffeine-it.com/openrasta/
I would also carefully read the licensing terms. From my reading (and I am not a lawyer), you cannot distribute the library with your code. That stopped us from using it in a product. It also stops you from using it in a client that you distribute to partners, etc.
I would second Greg's advice to favour ASP.NET MVC over the WCF REST starter kit. If you do go that route, make sure you look at this implementation of a RESTful controller in ASP.NET MVC.
