While browsing the SharePoint 2013 SP1 change log , I came across something really interesting:
2817429Minimal and no metadata are now enabled as supported JSON formats.
This really caught my attention as it was something I was waiting for. When we make a call with the REST API, there is a lot of additional data which we get back in the response. This additional data consists of the metadata and the Hyper Media Controls along with the required JSON data. To know more about this, please see this excellent post describing REST Maturity Models: http://martinfowler.com/articles/richardsonMaturityModel.html
This makes the payload size of the REST response too big. If you are developing a REST heavy application, then each extra byte of data that travels over the wire to your client adds up and ends up hampering performance.
I did some digging around and found out that my SharePoint Online Tenant was already supporting these JSON formats! All I had to do was to modify the Accept header of my REST call.
Note: As mentioned before, for these formats to work on an On-Premises SharePoint 2013, you will need to install SP1.
I ran some tests using the Chrome Developer Tools and Postman REST Client to see the effect on the payload size.
All tests were done to simply fetch the current web details with the following api call:
According to Microsoft Guidance published before, to get the JSON data back from the REST call, we need to specify the Accept header as "application/json;odata=verbose" But I think that guidance might be a little outdated now. Here is the result of the REST Call made with the above header:
Payload
Size: 2.0 KB
Content Size: 5.1 KB
And here is the JSON we get back. You can see that there is a lot of metadata along with the Hypermedia Controls.
Now when optimizing for performance, we do not need all the metadata and all the Hyper Media Controls as we are only concerned with the JSON data. We can then use this header to optimize them. It will return the required JSON with very minimal metadata attached to it. This is also the default option if you only specify "application/json" in your Accept header without specifying the odata parameter.
Payload
Size: 1.5 KB
Content Size: 1.0 KB
And this is the JSON returned. You can see that the Hyper Media Controls are no longer returned and only some of the metadata is returned.
This is the option for the extreme "optimizers" who want no metadata or Hypermedia Controls attached to the response and are only concerned with the JSON
Payload
Size: 1.4 KB
Content Size: 800 Bytes
And this is the JSON returned:
So as you can see, if you want to reduce the payload size from the REST response, you can use the different JSON formats depending on the degree of optimization you want.
Hope you found this information useful!
2817429Minimal and no metadata are now enabled as supported JSON formats.
This really caught my attention as it was something I was waiting for. When we make a call with the REST API, there is a lot of additional data which we get back in the response. This additional data consists of the metadata and the Hyper Media Controls along with the required JSON data. To know more about this, please see this excellent post describing REST Maturity Models: http://martinfowler.com/articles/richardsonMaturityModel.html
This makes the payload size of the REST response too big. If you are developing a REST heavy application, then each extra byte of data that travels over the wire to your client adds up and ends up hampering performance.
I did some digging around and found out that my SharePoint Online Tenant was already supporting these JSON formats! All I had to do was to modify the Accept header of my REST call.
Note: As mentioned before, for these formats to work on an On-Premises SharePoint 2013, you will need to install SP1.
I ran some tests using the Chrome Developer Tools and Postman REST Client to see the effect on the payload size.
All tests were done to simply fetch the current web details with the following api call:
https://siteurl.sharepoint.com/sites/test/_api/web
1) Accept : "application/json;odata=verbose"
According to Microsoft Guidance published before, to get the JSON data back from the REST call, we need to specify the Accept header as "application/json;odata=verbose" But I think that guidance might be a little outdated now. Here is the result of the REST Call made with the above header:
Payload
Size: 2.0 KB
Content Size: 5.1 KB
(Click on Image to Enlarge)
And here is the JSON we get back. You can see that there is a lot of metadata along with the Hypermedia Controls.
2) Accept : "application/json;odata=minimalmetadata" (OR Accept : "application/json")
Now when optimizing for performance, we do not need all the metadata and all the Hyper Media Controls as we are only concerned with the JSON data. We can then use this header to optimize them. It will return the required JSON with very minimal metadata attached to it. This is also the default option if you only specify "application/json" in your Accept header without specifying the odata parameter.
Payload
Size: 1.5 KB
Content Size: 1.0 KB
(Click on Image to Enlarge)
And this is the JSON returned. You can see that the Hyper Media Controls are no longer returned and only some of the metadata is returned.
3) Accept : "application/json;odata=nometadata"
This is the option for the extreme "optimizers" who want no metadata or Hypermedia Controls attached to the response and are only concerned with the JSON
Payload
Size: 1.4 KB
Content Size: 800 Bytes
(Click on Image to Enlarge)
And this is the JSON returned:
So as you can see, if you want to reduce the payload size from the REST response, you can use the different JSON formats depending on the degree of optimization you want.
Hope you found this information useful!