Request json option.

Apr 25, 2011 at 11:47 PM

Is it possible to request the data back in json format natively in sharepoint with SPServices?

I have been using this wonderful plugin ( which gives me a beautiful json object built from xdata.responseXML to work with.

(FYI its working GREAT with an awesome javascript templating library. This means no more messy html generation in js)

I would love to know if you could natively implement the above natively in SPServices - and if not how can i make a code pull request with an implementation of jquery-sharepoint-json as a plugin to Spservices?)



Apr 26, 2011 at 12:46 AM

We'd need to wait until Marc returns from vacation and logs on to get the official answer. The web service request is passed through jQuery's ajax function, which gives you the ability to specify the structure of the data returned, but I'm not sure how that would carry through SPServices as a whole (if you were to change it). My assumption is that any of the integrated parsing solutions would break. You're certainly welcome to change the type in the non-minified version and test it for yourself.

Apr 27, 2011 at 12:33 AM


You probably know that the SharePoint Web Services only serve up XML responses, no JSON. That said, there have been a few requests in the past to add a JSON option in SPServices. 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).

As far as a code pull goes, if you download SPServices, you have the code. That's all there is!


Apr 27, 2011 at 4:47 PM

p.s. On the code pull thing. SPServices is really just me. While people sometimes contribute code, it's usually relatively small stuff that I rework to include. So it's not really a collaborative effort like some open source projects. That's not to say that I don't want it to be, just that it has been.

Apr 27, 2011 at 5:24 PM
Edited Apr 27, 2011 at 7:09 PM

I understand marc,

I am very interested in contributing to the project and would love to see it become all that it can be.

A bit of background - I have been working with SharePoint for only a few months, but am an experienced ruby, php, javascript coder. In February I moved to Seattle from Australia for job with a microsoft vendor - and am currently almost exclusively working with SharePoint projects as a UI/UX consultant.

I see allot of potential for SPservices, especially as microsoft continues to ride the html5 marketing train. Spservices, in connection with html5 and css3 could really be used to make some impressive widgets and UI enhancements.

Look forward to working with you.

btw, do you mind if I make a mirror of Spservices on github? I would love to use git for version control. It is my fav for this type of project. 

EDIT: I have done so here:


Apr 27, 2011 at 7:17 PM

This article suggested json can be a natively returned format?

he is using getJSON which is the shorthand for the Ajax function sps is using.

It's equivalent to:

  url: url,
  dataType: 'json',
  data: data,
  success: callback

I will look to test out the above.
Apr 27, 2011 at 9:40 PM
Edited Apr 27, 2011 at 9:55 PM


That article is talking about the RESTful services which are available in SharePoint 2010. Generally SharePoint developers are accessing those services though the Client Object Model. It's a different access method, and equally valuable. However, AFAIK, it doesn't expose the range of operations that the XML Web Serives do. I've yet to see an apples to apples comparison.

When I started 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 becaose JSON wasn't yet as predominant as it is now (Boy, things can change fast!), I simply focused on getting the XML in and out.

Adding an XML-JSON tranlation service to SPServices is certainly an appealing idea. As I mentioned above, I've figured that the few of you who wanted if could find an additional plugin or roll your own. 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 be with SPServices is to not have *any* reliance on other plugin besides the jQuery library itself. This makes maintenance easier, if nothing else.

I'm interested in your additional thoughts as well as any help you might want to provide, of course! This is shaping into a nice blog post or two.


Apr 27, 2011 at 10:14 PM
Edited Apr 27, 2011 at 10:15 PM

Wow, thankyou for the clarification - shows how new I am to SharePoint.

An apples to apples comparison would be awesome - until then, I will look at creating the xml-JSON translation service within SPServices. I will take a dive into the code and see how messy it would be.

having JSON would really open up the library to some other pretty cool javascript libraries that are MVC based and/or have some cool view (html) and data bindings.

Client side apps!


Apr 27, 2011 at 10:23 PM

I think that the translation service would have to be totally content-neutral. In other words, you'd pass it some XML and it would pass back JSON. That's it. There are far too many variations in the XML that SharePoint sends back to even consider trying to cover them all. The way I'd see it working is simply to add a new option to SPServices called outformat or something, with the default being 'XML'. If the user passes 'JSON', then we translate, if not, we don't do anything new.

This makes it either much easier or much harder. You tell me!


Apr 27, 2011 at 10:24 PM

p.s. Watch for a blog post, coming tomorrow!

Apr 28, 2011 at 12:01 AM

I think that this is a great idea guys and am looking forward to seeing what comes of it. I am not that familiar with JSON, but have heard a lot of people are starting to use it. I would have to dig into more to see how it works. It seems promising!

Apr 28, 2011 at 12:13 AM

Yes that does make sense, since allot of your helper functions functionality expects xml and xml is the native response, it should be default.

The issue I do foresee is that creation of the json will be based on parsing and looping - particularly doing a foreach on  the [nodeName='z:row'] items of the xml. This isn't a problem for lists because thats the core item node, but for other xml responses and your built in helper functions the xml node names may be different.

I dont like the idea of creating a dictionary with the mappings, but i would much rather do so, than try to implement some type of xml 2 json converter. Even if we focused on lists first, and went to other services later that would be a great start.


look forward to the blog post.



Apr 28, 2011 at 2:06 PM

How about existing transporting formats, like jsonML ?

It seems that there are jQuery plugins that use jsonML, so it would play well with SPServices.

lukeholder, why do you want to use Web Services rather than the REST interface? Is it because you're on SharePoint 2007?

Apr 28, 2011 at 3:59 PM



im currently going with SPServices because based on the documentation it can do everything i need to within my current project. I am on 2010.

like Marc mentioned, there doesn't seem to be an apple to apple comparison around. Is there a jQuery rest plugin I am not aware of?


jsonML is what scares me about trying to do a straight converson, way to much cruft to parse out anyway, just as much effort as parsing the xml in jQuery.

if you take a look at - its exactly the functionality i would like in SPServices.



Apr 28, 2011 at 5:44 PM


SharePoint 2010 has a RESTful option available. You can read about it here:


Apr 28, 2011 at 5:53 PM


this looks like more to what  I would like to use


var url = 'http://localhost/sites/sharepointlist/_vti_bin/listdata.svc/InventoryLocations';
var inventoryLocation = {};

// Insert a new Part location.
inventoryLocation.PartId = $('#hidPartId').val();
inventoryLocation.BinNumber = $('#binText').val();
inventoryLocation.Quantity = $('#quantityText').val();

var body = Sys.Serialization.JavaScriptSerializer.serialize(inventoryLocation);

         type: 'POST',
         url: url,
         contentType: 'application/json',
         processData: false,
         data: body,
         success: function () 
           alert('Inventory Location Saved.');

Not to sound rude, but what is the benifit of SPServices over the above on SP 2010?

Apr 28, 2011 at 5:56 PM

Not so much, if you're strictly limited to using CRUD operations on list items. SPServices covers almost all the Web Services and not all are exposed via REST in 2010.


Apr 28, 2011 at 6:23 PM

Also Luke, keep in mind that there's a lot more to SPServices than just the GetListItems web service you're using it for. As Marc said, SPServices covers the gamut of SharePoint web services, including those not included in REST, and there's a growing library of custom functions included in SPServices such as the Cascading Dropdowns, Lookup add new, and Autocomplete (just to name a few). The SPServices library is far more than just reading a web service.

Apr 28, 2011 at 6:30 PM

Thanks webdes,

I understand. Looks like I will be using a combination of both. REST feels more lightweight and i will probably use it for my list interactions only.

I still would love to have json objects to work with on in SPServices.



Apr 28, 2011 at 10:45 PM

Compared to REST, Web Services/SPServices:

  • work on both SP 2007 and SP 2010
  • offer many more services, in particular for admin tasks
  • have convenient built-in functions for much needed features (like cascading drop-downs)

If you are on SP 2010 and just reading or updating lists, REST is just fine (that was the point of my first comment).

I was talking to Marc yesterday, and one option would be to create a sister library using REST instead of Web Services. I am going to do a test with cascading drop-downs.

Apr 28, 2011 at 11:38 PM

I would love to be apart of creating such a rest jquery lib for sharepoint.


Apr 29, 2011 at 3:11 AM

I just talked to Marc and I have started a new Codeplex project called SPrest:

The objective is to port the functions currently available in SPServices to the REST/json API.

I am starting with cascading lookups, as I was already working on it.

I'll set up the Codeplex repository access in the days to come. Here is a snippet of what I have so far:

$.SPrest= {

var CRUD={"Read":"GET","Create":"POST","update"="PUT","Delete":"DELETE"};
var type=CRUD[Crud]||"GET";
         type: type,
         url: "/"+Site+List+"/_vti_bin/listdata.svc/"+query,
         contentType: "application/json",

// End ListData

// End SPrest


Apr 29, 2011 at 4:13 AM

could you invite me to the project... it is not yet published and dont have access...

i already have a number of things in mind to add and improve.


Apr 29, 2011 at 4:25 AM

Luke, I haven't really started it yet.

Also, there are two different things here: make Web Services results available in JSON format, and use the REST API. The REST API is pretty much the 10 lines above (minus the typos), so before branching out from SPServices I'd like to make sure it's worth it.

Maybe your initial idea - mapping all services - is the right one, and REST would simply be a shortcut to avoid mapping list item services.

Apr 29, 2011 at 5:31 AM

FYI you will probably have to use the header option (only available in jquery 1.5 and above) to make use of the X-HTTP-Method header.

PUT, DELETE, and MERGE requests are needed to be submitted as POST request, and an X-HTTP-Method header passes the PUT, DELETE, and MERGE.



  headers: {
'X-HTTP-Method-Override', 'MERGE';
: 'POST'
// more parameters...



Apr 29, 2011 at 5:33 AM


Apr 29, 2011 at 1:22 PM

Luke, as you mentioned ou're new to SharePoint, I also wanted to point out that AJAX is not necessarily the answer to everything SharePoint. In particular, one issue Marc and I have run into is that these AJAX calls are not meant to work in anonymous environments. No REST API on the Internet. For Web Services, Marc has discovered a way to make it work, but this is undocumented on the Microsoft site and we never had confirmation that it was a regular approach. That explains why I often resort to RSS feeds and screen scraping for client side code...

Apr 29, 2011 at 4:55 PM

I understand it is not the answer to everything - but in my case I am far more confortable using it and I am working in a fully authenticated environment. (Microsoft's Intranets)

Does SPServices perform screen scraping techniques?


Apr 30, 2011 at 12:10 AM

Data retrieval in SPServices is done exclusively with Web services.

Functions like SPCascadeDropdowns do DOM exploration to figure out the underlying structure, not sure if this qualifies as screen scraping.

Apr 30, 2011 at 1:48 AM

SPServices itself doesn't do "screen scraping", but jQuery allows SPServices to locate and use values in the DOM.

I used to write programs to do screen scraping stuff long ago, and this is really quite different. The DOM in a Web page is really well-structured data, and you can treat it as such.


Apr 30, 2011 at 3:15 AM

Luke, to continue the discussion about xml to JSON, two comments:

1/ what would be the benefit of including your plugin in SPServices, as opposed to keeping it as an add-on? One reason for keeping it separate is that part of the audience are not developers, and only care about the functions like SPCascadeDropdowns.

2/ Now that you know about the REST API, would it make sense that your plugin uses the same output format (d.results.etc.) as Microsoft for JSON? This way, the tools you develop would be compatible with both SPServices and the REST API.

Apr 30, 2011 at 3:53 PM

Me again... I just found this in the jQuery doc (, maybe it could help:

As of jQuery 1.5, jQuery can convert a dataType from what it received in the Content-Type header to what you require. For example, if you want a text response to be treated as XML, use "text xml" for the dataType. You can also make a JSONP request, have it received as text, and interpreted by jQuery as XML: "jsonp text xml." Similarly, a shorthand string such as "jsonp xml" will first attempt to convert from jsonp to xml, and, failing that, convert from jsonp to text, and then from text to xml.

So it seems that a dataType "xml json" or "xml text json" would convert the returned xml to JSON?

Apr 30, 2011 at 5:31 PM

I'm fiddling with this a bit with no success. I seem to get parser errors in all of the variations I'm trying. It would be totally awesome for this to work, of course!


Apr 30, 2011 at 6:02 PM

It's not what I initially thought. Apparently it works with another option called converters. Simple text to * conversions are there by default, but advanced ones will require to include your own converter. This could be an easy way to plug Luke's converters to SPServices (for jQuery 1.5+).

May 1, 2011 at 3:29 AM

Marc and Luke: I have uploaded a first draft of SPrest (v0.0.1, size...1KB), and an example.

May 1, 2011 at 4:25 AM

I cannot see the files anywhere in the project site. including svn server.

May 1, 2011 at 4:33 AM

I have sent you a direct message. My apologies for polluting this discussion.

What do you think of my previous comments? "converters" looks like what we're looking for.

Dec 24, 2011 at 4:56 AM
Edited Dec 24, 2011 at 4:58 AM

I too only recently found out that SharePoint 2010 supports the REST API for CRUD operations. I had already built my own custom JS library which does the XML Web service calls (using SPServices) and returns the data in JSON format. I built this mainly to replace the Backbone.js CRUD operations with SharePoint equivalents.

Would this be a good addition to SPServices? If yes, I can share the code here or in a new discussion.

Dec 29, 2011 at 2:56 PM


I've love to see your code. I've been thinking about adding a simple XML to JSON conversion for GetListItems for a long time; it may be about time to do it. How about posting to a new discussion thread.


Dec 29, 2011 at 3:45 PM

The following should work for converting GetListItems output to json:

function convertXmlToJson(){
    var json = [];
        operation: "GetListItems",
        async: false,
        listName: "your_list_name_here",
        CAMLRowLimit: 0,
        completefunc: function(xData, Status) {
            var i = 0;
            $(xData.responseXML).find("[nodeName='z:row']").each(function(n,v) {
                var rowAttr = this.attributes;
                var total   = rowAttr.length;
                for (var e=0; e<total; e++) {
                    json[n][rowAttr[e].nodeName] = rowAttr[e].nodeValue;
    return json;

As you can see, I'm not yet using SPSservice 0.7.x... so you will need to change ti to use the new way to get the z:row items out of the response.


Dec 29, 2011 at 3:47 PM

Awesome, Paul. Thanks.


Dec 29, 2011 at 3:57 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Dec 30, 2011 at 6:29 PM

Please see my blog post about including an XML to JSON conversion capability in SPServices and let me know what you think.