Looking for JSON recommedation/suggestions

[kevininstructor]

Our team (currently work with VB.NET) is moving towards REST and JSON to develop with. Instead of simply doing a typical Google search (which I did some already) to see what is out there I am looking for anyone who has or is currently working with JSON and shares anything that might assist me moving forward. I am not looking for code but instead helpful web links and advice from your experiences. Thanks in advance for any input.

Some of my startup resources so far so not to duplicate
http://json.org/ http://msdn.microsoft.com/en-us/library/bb410770.aspx http://jsonviewer.stack.hu/ http://developer.yahoo.com/yql/console/ (I like the idea you can toggle between xml and json)

[dilettante]

To some extent it depends on the client technologies you are using. Are these browser-based clients or real desktop clients? True desktop or Metro?

It matters because Microsoft provides varying levels of JSON support (and different libraries) in each environment. Though if you are captive to the Web you'll have to deal with whatever broke-leg capabilities that work cross-browser.

[kevininstructor]

This might clear things up a bit too.

I work for Oregon’s Department of Revenue where we deal with the feds (IRS), a large array of partners (tax software companies i.e. Intuit), and other state agencies. With that said there are times it makes sense to go in one direction simple because the feds have dictated this because of rules they have which we must follow while on the other end of the spectrum we need to be fluid with partners (software companies and state agencies). We are exploring all forms of mobile to work with partners and taxpayers. Couple this up with a major system replacement (I am talking over 90 million dollars) which to us will essentially be a black box. Meld this together means we need to be fluid.

Almost left the following out Oregon Central Business Registry which is for private businesses which we are part of.

[dilettante]

I feel your pain. Here's one I was involved with a few years back (until I got off that sinking ship):

http://www.freep.com/article/2012072...n-report-shows

This is a rather common outcome of such efforts, sadly enough. With some Googling you can find these train wrecks in nearly every State in the Union.


But that aside I'm not sure how any of that makes a difference. Maybe a better approach might be to ask what kinds of info you are asking for pointers to?

Do you want the technical mechanics of JSON? What JSON libraries are available? Because pretty much anything "high level" is the same for REST (with JSON payloads or not) as it is for SOAP and any other format of Web Service.

Perhaps you don't have a ton of Web Service background. That makes a difference, because you'll probably want to know more about the security, scalability, reliability, administration, versioning and servicing and other issues associated with Web Services. Perhaps discussions of the merits vs. pitfalls of SOAP's tight-coupled model vs. more loosely-coupled approaches.


To some extent that's a tall order. A lot of these issues were widely discussed when these technologies were new 7 to 9 years ago. Most information you'll find readily available now assumes all of that as background, making current discussions frustratingly opaque to newcomers.

The one advantage you have is that around the release of VS 2005 Microsoft did a "big reset" quietly downplaying SOAP and moving toward REST to improve interoperability and shrug off the headaches of tight coupling. So a lot of old discussions got rehashed ("discovered") on Microsoft blogs from 2004 through 2007 or so. This means some older issues got "refreshed" and might still be online.

[kevininstructor]

Do you want the technical mechanics of JSON? What JSON libraries are available? Because pretty much anything "high level" is the same for REST (with JSON payloads or not) as it is for SOAP and any other format of Web Service.

That is basically what I am looking for. I figured, sure the simple thing to do is Google for info but as we all know sometimes it is better to look for knowledge from someone who has already done this in regards to a) finding information b) has tripped on the perverbal landmind.

Perhaps you don't have a ton of Web Service background. That makes a difference, because you'll probably want to know more about the security, scalability, reliability, administration, versioning and servicing and other issues associated with Web Services. Perhaps discussions of the merits vs. pitfalls of SOAP's tight-coupled model vs. more

I have little expereince with Web Services. The good thing is we have three out of five web developers (ColdFustion, Java, JQuery and JavaScript backgrounds) that have been writing services. Two others (on another team) who are well verse with (stealing your words) security, scalability, reliability, administration, versioning and servicing. One of these is part of the agencies security team so these topics (not my expereince) are covered for that side of the Java fence, I am diving in on the .NET side of things where my team mate does SOAP with federal data exchanges which for what we want is considered to heavy.

The one advantage you have is that around the release of VS 2005 Microsoft did a "big reset" quietly downplaying SOAP and moving toward REST to improve interoperability and shrug off the headaches of tight coupling. So a lot of old discussions got rehashed ("discovered") on Microsoft blogs from 2004 through 2007 or so. This means some older issues got "refreshed" and might still be online.

Well that is good to know!

[dilettante]

Yeah, Web searches are probably a way to get your feet wet. I'm sure they'll turn up things like An Introduction to JavaScript Object Notation (JSON) in JavaScript and .NET as a jumping-off point. You might try making some sense of the Wikipedia entry https://en.wikipedia.org/wiki/JSON first if you haven't yet.

In essence though the JavaScript part of JSON is almost irrelevant, and lots of JSON libraries don't use a JavaScript engine at all - or at best a vestigial optimized subset engine. Remember, JSON is merely an alternate cross-platform serialization format for data structures, just like CSV, INI, XML, YAML, COM PropertyBags, etc.

In most of your programming you'll simply pass data strcutures into a generator to get JSON out, and JSON into a parser to get data structures back. Depending on the library, the data structures might be DOM-like or almost anything else such as collections of collections of simple value objects, or more specific persistable object types - though that gets you back to the tight coupling woes and associated versioning headaches.