3 ms·

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 ser

by 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.

by mythz 16y ago

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.