Project 31-A

One of the pains with using REST is getting the data from JSON into something usable. There is a very simple solution:  Take the JSON, pass it to a magic black box and get a dataset back that has foreign keys and other joys.   That sounds very nice -- Make the JSON REST call and then Query or filter data tables to do future processing. No need to define classes to deserialize the JSON into..... The code is horrible and shown below... using System; using System.Linq; using System.Data; using System.Xml; using Newtonsoft.Json; namespace Avalara.AvaTax.JsonUtilities { public static class Utility { public static DataSet ConvertJsonToDataSet(string jsonText, string rootElementName) { var xd1 = new XmlDocument(); xd1 =JsonConvert.DeserializeXmlNode( jsonText,rootElementName); var result = new DataSet(); result.ReadXml(new XmlNodeReader(xd1)); return result; } } } To put this into a f

A while back I was contacted to solve a quasi-nasty issue. An existing REST implementation had been updated with an extra field being added to the response. This worked fine for 99% of the consumers, but for one consumer it broke. This consumer wrote a package that they sold on to others and their customers were screaming. The reason it broke was that it was not coded to handled additional fields. Technically, REST is an architectural pattern without standards . Robustness in handling extra fields and data is what most developers would expect -- but that is not a requirement of REST. It is hopeful thinking. If the REST was well versioned, this issue would not have arisen. It did arise. While this consumer can patch their code, getting the patch to all of their customers was problematic hence there was a need to do an immediate fix, somehow. Fortunately, their package allows the REST Url to be specified and that allow a simple quick solution. Create a "Relay Website" up

REST implementations are often tossed up without much thought. REST is an architectural style  and lacks any standards. A frequent issue is no consideration to versioning. In this post I will attempt to develop a checklist of items that would be in an ideal REST implementation. Content Negotiation This means being aware of what a requesting agent will accept and the requested precedence. Wikipedia . For example: Accept: text/xml; q=1.0, text/html; q=1.0, text/JSON; q=0.9,  text/csv; q=0.85, text/*; q=0.8, image/gif; q=0.6, image/jpeg; q=0.6, image/*; q=0.5, */*; q=0.1 Then the rest should return XML as the first choice, html as the second choice (if XML is not supported), then JSON, CSV, CSV.  If the request is for data that could be charted, then the fall thru would be to return an image of chart....  Got it? So the checklist should be a list of formats supported. My own preference is to support XML as first priority (because it can provide a Schema Definition  or WSDL -