

REST Media Types, SOAP, Heavy frameworks and Literate Programming - mythz
http://www.servicestack.net/mythz_blog/?p=665

======
lucisferre
Very good post. I generally (heck even wholeheartedly) agree with most of what
is being said, however I'll take some small issue with a couple of things.

While the comments about .NET and Java are more than fair, things are starting
to improve (albeit slowly). The new WCF REST bits that are up on Codeplex and
are actively being developed by Glenn Block and his team look quite promising.
I've also been working with a nascent .NET framework called Nancy
(<http://github.com/thecodejunkie/Nancy>), which is extremely lightweight,
very extensible and inspired by Sinatra's syntax.

Second, I'll agree that in general right now implementing proper Hypermedia
support seems like more pain than gain. However, my experience so far is
already indicating places where having hypermedia support would make things
easier on me in terms of client development. The challenge is finding a
convenient and reasonably DRY way to build in hypermedia support into my API.
So while I don't care that my API isn't fully REST, I still think there is
value to be gained in exploring the 'harder' things like hypermedia.

~~~
mythz
Hi and thanks,

Yeah I know of NancyFx and Glenn's WCF Web APIs and follow both closely - if
you haven't had a chance yet you should also checkout
<http://servicestack.net> which allows you to create some pretty responsive
demos with just 1 page of C# (definitely in-line with my pursuit of DRY, fast
and expressive code :).

So what I'm trying to pitch is for not a blind pursuit of conformance but to
recognize the value that it provides and whether it's actually worth the
effort. But yeah I'm constantly striving for better development practices,
tools, designs, etc. But in the sea of tech I don't take anything at facevalue
(no matter who preaches it) and need to be proven of value before I adopt it.

------
regularfry
I wonder how the author would feel about, say, a 1:1 JSON remapping of vCard
with its own media type?

~~~
mythz
It's not the agreed format that I have an issue with (that's actually the only
thing of value). It's the effort required to create the media type. In my web
services I can just return a c# POCO, e.g. new Customer{Name=,Age=,etc} - this
POCO gets automatically converted into the dataformats requested and therefore
takes no effort on the server to implement. On the client (say in ajax) you
can simply get the json object with var contact=JSON.parse(contactDto); (i.e.
for free).

This is the effort to implement just the serialization of the VCard media type
on the server: [http://www.servicestack.net/ServiceStack.Northwind/vcard-
for...](http://www.servicestack.net/ServiceStack.Northwind/vcard-format.htm)
which doesn't include the deserialization routine which because it is custom
(i.e. not a data format) takes a lot more effort. So unless the client has
auto support for the VCard format why would you opt-in the extra effort to do
this?

~~~
regularfry
I regard that as a solved problem, really. It's just not worth the bother
using anything for which there isn't a pre-packed parser in the browser (or
whatever other client might be relevant).

I'm _much_ more interested in the design of restricted formats, though. It's
not much good sending Accept: application/json when the interface will barf if
you miss a critical key or two from the subset of json it's expecting.

~~~
mythz
Sure, tho I would consider the url as a good indication of the expected
response. Adding the strong-typed Content-Type for every data response is
reminiscent of the SOAPAction days. This is one of the areas where I don't
think it provides much value since most/all of the times the client already
knows what the 200 response will yield. So in this case I consider it just
introduces another friction point that adds littler or no value.

My personal opinion is that it only makes sense for 'Dumb' HATEOS clients that
rely on it to delegate it to the appropriate renderer. i.e. not the clients
I'm used to seeing developed.

