2

I read about JSON Light support for SharePoint REST APIs and tried to use it to save some bytes when calling the SharePoint Search REST API (/_api/search).

I get unexpected behavior with nearly all of the Accept header values of the JSON Light spec. Here are the results:

  1. Accept: application/json;odata=verbose -> works as expected, returns results as JSON
  2. Accept: application/json -> returns results as XML!
  3. Accept: application/json;odata=minimalmetadata -> returns results as XML!
  4. Accept: application/json;odata=nometadata -> returns results as XML!

(The farm is SP 2013 Enterprise on CU June 2016, if that matters.)

And here are my questions about this:

  1. What is the current state of JSON Light support with regards to the SharePoint Search REST API? Is it supported? Should the above work?
  2. Is there documentation about this? Like a list of APIs which support JSON Light? I cannot remember reading about this in the SharePoint REST docs.
  • 1
    I just ran into this issue with /_api/web/currentuser. Only verbose actually returns JSON. I think we have a similar updated state on our Farm too. – Rothrock Nov 9 '16 at 1:41
1

With SharePoint 2013 SP1, you should see the version 5.6 of the following assemblies in the GAC ( C:\Windows\Microsoft.NET\assembly\GAC_MSIL ):

Microsoft.Data.Edm Microsoft.Data.Odata Microsoft.Data.Services.Client Microsoft.Data.Services System.Spatial

You will probably find version 5.0 and version 5.6. Right click on the assembly, properties, details tab.

If not, you need to install WCF Data Service 5.6. I didn't find an installer for windows server 2012 and discovered they were already installed but not registered.

Now that they are installed, you need to register them with a powershell script (see: https://msdn.microsoft.com/en-us/vsto/dn762092(v=office.14).aspx )

$configOwnerName = "JSONLightDependentAssembly"
$spWebConfigModClass ="Microsoft.SharePoint.Administration.SPWebConfigModification"

$dependentAssemblyPath ="configuration/runtime/*[local-name()='assemblyBinding' and namespace-uri()='urn:schemas-microsoft-com:asm.v1']"
$dependentAssemblyNameStart ="*[local-name()='dependentAssembly'][*/@name='"
$dependentAssemblyNameEnd = "'][*/@publicKeyToken='31bf3856ad364e35'][*/@culture='neutral']"
$dependentAssemblyValueStart = "<dependentAssembly><assemblyIdentity name='"
$dependentAssemblyValueEnd ="' publicKeyToken='31bf3856ad364e35' culture='neutral' /><bindingRedirect oldVersion='5.0.0.0' newVersion='5.6.0.0' /></dependentAssembly>"
$edmAssemblyName ="Microsoft.Data.Edm"
$odataAssemblyName ="Microsoft.Data.Odata"
$dataServicesAssemblyName ="Microsoft.Data.Services"
$dataServicesClientAssemblyName ="Microsoft.Data.Services.Client"
$spatialAssemblyName ="System.Spatial"
$assemblyNamesArray = $edmAssemblyName,$odataAssemblyName,$dataServicesAssemblyName,$dataServicesClientAssemblyName, $spatialAssemblyName
if ( (Get-PSSnapin -Name Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue) -eq $null )
{
    Add-PsSnapin Microsoft.SharePoint.PowerShell
}
$webService = [Microsoft.SharePoint.Administration.SPWebService]::ContentService

################ Adds individual assemblies ####################
For ($i=0; $i -lt 5; $i++)
{
    echo "Adding Assembly..."$assemblyNamesArray[$i]
    $dependentAssembly = New-Object $spWebConfigModClass
    $dependentAssembly.Path=$dependentAssemblyPath
    $dependentAssembly.Sequence =0 # First item to be inserted
    $dependentAssembly.Owner = $configOwnerName
    $dependentAssembly.Name =$dependentAssemblyNameStart + $assemblyNamesArray[$i] + $dependentAssemblyNameEnd
    $dependentAssembly.Type = 0 #Ensure Child Node
    $dependentAssembly.Value = $dependentAssemblyValueStart + $assemblyNamesArray[$i] + $dependentAssemblyValueEnd
    $webService.WebConfigModifications.Add($dependentAssembly)
}
###############################################################

echo "Saving Web Config Modification"
$webService.Update()
$webService.ApplyWebConfigModifications()
echo "Update Complete"
0

It has been awhile.. we wrote our own Native JS no-jQuery wrapper around all this...

I see we had a overrideMimeType to deal with it (we only do O365 now)

//xhr.overrideMimeType("application/jsonp");// old SharePoint did XML by default?
try {
    xhr.responseType = Xhr_responseType || (url.indexOf('.html') > 0 ? 'text' : 'json');//please give me the results in JSON format
} catch (e) {
    xhr.responseType = Xhr_responseType || 'text'; //safari doesn't handle json responsetype in older versions
}

Note: to handle/flatten the different response structures we have:

/* return one style JSON response; proces 3 types of responsestructures (verbose,minimalmetadata,nometadata */
    ['value', 'd', 'results'].map(function (property) {
        if (response.hasOwnProperty(property)) response = response[property];
    });
  • Ok I'm trying to fit your information into my perspective. Are you saying I should play with overriding the mime type? What role plays flattening the response structure? I'm trying to not get the data in the first place - are you doing something on the server side? – Heinrich Ulbricht Nov 9 '16 at 9:14
  • 1
    No, nothing server side. As I recall the overrideMimeType was needed (but only in older SharePoint versions/) to tell it to not deliver XML.. this goes many moons back.. I extracted this from sources I haven;t seen in over a year – Danny '365CSI' Engelman Nov 9 '16 at 9:32
0

I read this article explaining how it can be enabled.

https://technet.microsoft.com/en-us/library/dn762092(v=office.15).aspx

Unfortunately, in my on premises 2013 SP instance, this breaks functionality working with SP.ClientContext - executeQueryAsync

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.