14 ms·

REST Media Types, SOAP, Heavy frameworks and Literate Programming

15 points by mythz 16y ago

lucisferre 16y ago
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 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 16y ago
  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 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 16y ago
I wonder how the author would feel about, say, a 1:1 JSON remapping of vCard with its own media type?
- mythz 16y ago
  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-format.htm http://www.servicestack.net/ServiceStack.Northwind/vcard-for... 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 16y ago
    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 16y ago
      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.

15 points by mythz 16y ago

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 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 16y ago
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 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 16y ago

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

mythz 16y ago
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-format.htm http://www.servicestack.net/ServiceStack.Northwind/vcard-for... 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 16y ago
  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 16y ago
    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.