[NoBrainer] Saving bandwidth with JSON when consuming ODATA services from PowerShell

When working with ODATA sources from PowerShell via a service reference (instead of using explicit REST call via Invoke-RestMethod) the .NET DataServiceClient will use Atom/XML under the hood. This works perfectly well except it consumes much more bandwidth because of the XML data format. As the whole ODATA interface is encapsulated via your service reference it really does not make sense or gives you real advantage to use XML instead of JSON.

So in order to switch, you just need to use:

$ls.ApplicationData.Format.UseJson();

… and there you are. For a quick introduction on how to use the LightSwitch data model from PowerShell you can have a quick look at LightSwitch: Modifying roles, permissions and users via PowerShell. In short, you just have to create an empty class library with a service reference in Visual Studio, compile it and add the type of the assembly to your session.

For a quick comparison here are two queries to the same resource (11 records) where only the ‘Name’ attribute of an entity is returned (via ‘$select’). As you can see the Content-Length for the XML response is 6319 bytes in contrast to the JSON response with only 2940 bytes (less than the half). And this example is only for a small result set. When querying larger entity sets the repeating XML schema declarations and tags will add up significantly. So go for JSON and change today …

HTTP/1.1 200 OK
Cache-Control: private
Content-Length: 6319
Content-Type: application/atom+xml;type=feed;charset=utf-8
Server: Microsoft-IIS/8.0
X-Content-Type-Options: nosniff
DataServiceVersion: 1.0;
X-AspNet-Version: 4.0.30319
Persistent-Auth: true
X-Powered-By: ASP.NET
Date: Sun, 10 Aug 2014 18:07:32 GMT

<?xml version="1.0" encoding="utf-8"?>
<feed 
	xml:base="http://www.example.com/ApplicationData.svc/" 
	xmlns="http://www.w3.org/2005/Atom" 
	xmlns:d="http://schemas.microsoft.com/ado/2007/08/dataservices" 
	xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata">
	<id>http://www.example.com/ApplicationData.svc/EntitySet</id>
	<title type="text">EntitySet</title>
	<updated>2014-08-10T18:07:33Z</updated>
	<link rel="self" title="EntitySet" href="EntitySet" />
	<entry m:etag="W/&quot;X'000000000001B595'&quot;">
		<id>http://www.example.com/ApplicationData.svc/EntitySet(3006)</id>
		<category term="LightSwitchApplication.Entity" scheme="http://schemas.microsoft.com/ado/2007/08/dataservices/scheme" />
		<link rel="edit" title="Entity" href="EntitySet(3006)" />
		<title />
		<updated>2014-08-10T18:07:33Z</updated>
		<author><name /></author>
		<content type="application/xml">
			<m:properties>
				<d:Name>Schnittenfittich</d:Name>
			</m:properties>
		</content>
	</entry>
	<!-- remaining result records have been removed for better readability -->
</feed>
HTTP/1.1 200 OK
Cache-Control: private
Content-Length: 2940
Content-Type: application/json;odata=fullmetadata;streaming=true;charset=utf-8
Server: Microsoft-IIS/8.0
X-Content-Type-Options: nosniff
DataServiceVersion: 3.0;
X-AspNet-Version: 4.0.30319
Persistent-Auth: true
X-Powered-By: ASP.NET
Date: Sun, 10 Aug 2014 18:07:43 GMT

{"odata.metadata":"http://www.example.com/ApplicationData.svc/$metadata#EntitySet&$select=Name",
	"value":[
		{"odata.type":"LightSwitchApplication.Entity"
		,
		"odata.id":"http://www.example.com/ApplicationData.svc/EntitySet(3006)"
		,
		"odata.etag":"W/\"X'000000000001B595'\""
		,
		"odata.editLink":"EntitySet(3006)"
		,
		"Name":"Schnittenfittich"}
		// remaining result records have been removed for better readability 
	]
}

Comments

  1. Ramonitor says:

    Hi, thanks for your blog. I was wondering if you found a way to expose Lightswitch queries via the WCF wrapper. I can only access the entities itself.

    • Ronald Rink says:

      Hi Ramonitor, I do not know a way either on how you could do this directly via the WCF Wrapper. However, I wrote a post about ODATA Service Actions (https://d-fens.ch/2014/08/14/nobrainer-using-odata-actions-via-powershell/) and a follow up to it. You should be able to use the same technique as described in the second post to call these queries and then convert the response to native .NET objects. Hope this helps you. Regards, Ronald

      • Ramonitor says:

        Excellent. Much appreciated. I somehow missed that one. Will check it out. :)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: