SPServices, XML, JSON, and REST–Thoughts?

ByMarc D Anderson

Over the last few months, I’ve had a couple of requests for SPServices to emit JavaScript Object Notation (JSON) in addition to Extensible Markup Language (XML). This is probably a natural progression, as SharePoint developers are becoming more familiar with the JSON approach, which IMO has been traditionally known far better by Web developers.

In my simplistic view, JSON and XML are simply different notation methods for passing data from one place to another. One doesn’t seem grandly better or worse than the other, though there are some key differences. These are the differences as I see them with no research on the concepts. (I sometimes like to keep my mind free of the conventional wisdom, as it can clutter the simplicities of the topic.)

  • XML has far more contextual padding. Every data value in XML has the familiar <wrapper>around it</wrapper>.
  • JSON is lighter, in that it only has delimiters like {}, commas, and [].
  • JSON is more “modern”, meaning newer. That alone is often enough of a driver for people to switch, though it’s hardly a good reason other than for resume build-out.
  • Both methods must deal with characters which have other meanings in an HTTP request. Those characters are delimited so that they can be passed without being interpreted with their reserved meanings.
  • To use either method, the developer must understand the internal structure of the data. While both have implied structure, it’s no different than the old client-server or EDI days: you must understand what you are getting in those containers in order to make sense of it.

Both methods have their plusses and minuses, but to me it’s simply another religious debate like PCs vs. MACs. Both get the job done, and there are times when one may have an advantage (however slight) over the other. I’m absolutely certain that there are volumes of rants pushing in either direction all over the InterWebs.

When I started working on SPServices, SharePoint 2010 wasn’t yet generally available, though I think that there was probably a CTP or something out there; I just didn’t have access to it. Because of that, and because JSON wasn’t yet as predominant as it is now (boy, things can change fast!), I simply focused on getting the XML out and in.

SharePoint 2007’s Web Services (.asmx) only emit XML. You pass a Simple Object Access Protocol (SOAP) request to the Web Service and the Web Service passes XML back. QED. SharePoint 2010 has added the Client Object Model (Client OM), which allows you to retrieve data in the JSON format via those RESTFul services (.svc).

Adding an XML to JSON translation service to SPServices is certainly an appealing idea. I’ve balked a bit, figuring that anyone who knew enough to ask for it also knew enough to find a plugin to convert XML to JSON or to build one. And then maybe they’d even contribute it to SPServices (wink, wink). Also, SharePoint developers (most of whom are .NET developers) may not be as familiar with JSON as XML, though clearly that is changing.

Another tenet I’ve tried to live by with SPServices is to not have *any* reliance on other plugins besides the jQuery library itself. This makes maintenance easier, if nothing else. That’s why I’ve avoided trying or recommending any other plugins which might emit JSON or building any ties to them.

Remember that I cannot tell the SharePoint Web Services what to pass: they pass XML. What I *could* do is add a translation facility, which would obviously add overhead to the process. This definitely would be a performance hit; there’s no way around that.

So, if you are an SPServices user, what are your thoughts on XML vs. JSON? Can you give any concrete examples of why you *really, *really* need JSON?

Similar Posts

11 Comments

  1. I was just reading articles about JsonML when I was notified of your post…

    I wouldn’t make it a strict rule to exclude plugins or libraries. After all, you’ve accepted to systematically work with jQuery in the first place (I haven’t). For example, JSON.parse and JSON.stringify were plugins before becoming mainstream.

    The format choice is also bound to the tools available. XML is a natural choice when working with xslt, and JSON works well with JavaScript/jQuery. I expect the templating trend to continue, and that will make JSON more relevant for client side code.

    Also, I think your reflection should go beyond the simple data format. It’s also about whether the new REST interface has its place in SPServices.

    Reply

    1. Christophe:

      It’s not that I wat to exclude using other libraries: quite the contrary. It’s more that I don’t want to say “This piece of SPServices will only work if you have the bugaboo plugin.” Meaning that I want it to stand alone and work fully.

      REST has its place in SharePoint, absolutely, but I’m being pretty careful about it for SPServices. Since the genesis for the whole thing was 2007, and I expect that is still where a large portion of the work happens, I’m still thinking about how to (or whether to) take advantage of the 2010 features like REST and the modal dialogs. I’ve vascillated between thinking about splitting into two versions and simply expanding. That vascillation has led me to do nothing!

      M.

      Reply

  2. Personally, I have been using SPServices a lot and love the XML handling — but there are some significant performance gains in dealing with JSON data over the raw XML put out by the SOAP web services — not only does the notation come in a much lighter-weight format (without all the xml), it is much easier to parse in the browser since you are using javascript objects — these collections can be somewhat strongly typed, and that makes more sense when reading through code.

    However, if you’re going to simply translate the XML into some type of JSON notation, it would be a wasted effort since no performance gains would be realized. It’s easy enough to deal with the XML data — although not as lightweight.

    Reply

  3. The main reason I was hoping to see JSON formatted data is the ease in which i could integrate SPSservices with the crazy popular javascript libraries around at the moment – nearly all of them based around MVC within the browser. This means/includes client side templating.

    see:
    http://knockoutjs.com/
    http://documentcloud.github.com/backbone/
    http://documentcloud.github.com/underscore/

    I could take a json object and pass it to a template and have i prepared and even have the view bind (bound) to the model of data. (i.e refresh the json model from the server and the view updates)

    i cringe when i see things like this:

    $(xData.responseXML).find("User").each(function() {
  $("#WSOutput").append("ID: " + $(this).attr("ID") + "");
  $("#WSOutput").append("Sid: " + $(this).attr("Sid") + "");
  $("#WSOutput").append("Name: " + $(this).attr("Name") + "");
  $("#WSOutput").append("LoginName: " + $(this).attr("LoginName") + "");
  $("#WSOutput").append("Email: " + $(this).attr("Email") + "");
  $("#WSOutput").append("Notes: " + $(this).attr("Notes") + "");
  $("#WSOutput").append("IsSiteAdmin: " + $(this).attr("IsSiteAdmin") + "");
  $("#WSOutput").append("IsDomainGroup: " + $(this).attr("IsDomainGroup") + "");
  $("#WSOutput").append("");

    when i could have something like this…

    <ul>
  <li>data-bind="value: ID" /></li>
  <li>data-bind="value: Sid" /></li>
  <li>data-bind="value: Name" /></li>
  <li>data-bind="value: LoginName" /></li>
  <li>data-bind="value: Email" /></li>
  <li>data-bind="value: Notes" /></li>
  <li>data-bind="value: IsSiteAdmin" /></li>
</ul>

    With the above bound with knockout.js with the SP list model in JSON format.

    Reply

  4. Please don’t waste *your* time converting XML to JSON. I’d rather you spend your time on the things I can’t do (well, would prefer not to do). When I want to convert XML to JSON for use with plugins for templating or whatever, I just parse the XML with jQuery then use $.map to convert to JSON/JavaScript objects.
    Don’t bloat your code with converters I can easily write.
    Now if/when you start leveraging APIs that natively return JSON… well, then stick with that format for those calls. Your library makes a lot of SharePoint work a lot easier but doesn’t need to do *all* the coding.

    Reply

  5. Oh, crap. You put me on the spot. Bear in mind that I am an eager student of software development but not an expert. I saw this concept used somewhere (perhaps on this site, perhaps on the jQuery site) but have no clue where. Also keep in mind that I know this is inefficient, but that I use it specifically so that I can leverage jQuery templating. For that reason, I’m including a two-line template example too (hard-coded in-line and not what I would normally do.)

    // Convert an xml list of groups to an array of JSON objects suitable for template binding
var laGroups = $(xData.responseXML).find("Group").map(function(lcv, o) { return {Name:$(o).attr("Name")} }).get();
// Now use templating to generate a set of li tags:
var li = $.tmpl("<li>${Name}</li>", laGroups);
// Replate my place holder with the generated objects.
$("#GroupItemTemplatePlaceHolder").replaceWith(li);
    Reply

    1. OK, that is very cool. Haven’t played with it yet, but that’s one more thing I don’t have to write.
      Thanks, Luke.

      Reply
  7. Pingback: Two new projects: SPrest and SPELL « Path to SharePoint

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.