Rise Foundation

Blog Categories


Posts Tagged ‘OData’

Configuring SharePoint 2013 Preview for On-Premise Apps

Since Apps are the “next big thing” for SharePoint, from an opportunity perspective, expect to see a lot of hullaballoo about how you should create apps because they’re going to be the greatest thing to happen to SharePoint since Shared Service Applications replaced the Shared Services Provider.  However, not all apps are created equal, and apps can be created in several varieties.  This blog is focused on setting up the flavor that the developer has the most control over: On-Premise Apps.

Update: After receiving a bunch of issues with Host Headers, I’ve posted a new blog covering host headers for both web applications and site collections here: SharePoint 2013 Apps and Host headers

Configuring SharePoint 2013 Preview for On-Premise Apps

On-Premise Apps are difficult to set up because you have to do all of the setting up to get your apps hosted on SharePoint manually.  There’s no pre-configured Office 365 environment for you to use.  Unfortunately, none of these steps can be done through the UI other than the creation of a Developer Site.  To successfully develop SharePoint On-Premise Apps, you need a Developer Site Collection, a pair of Shared Services Applications, running Shared Services Instances, the Office Developer Tools for Visual Studio 2012 Release Candidate, and an App Domain and prefix.  I’ll step through each item below.

Note: Microsoft has a guide just like this one on their SharePoint 2013 documentation site: How to: Set up an on-premises development environment for apps for SharePoint []

Read the rest of this post »

Client data access with OData and CSOM in SharePoint 2013

SharePoint 2013 has improved OData support. In fact, it offers full-blown OData compliant REST based interface to program against. For those who aren’t familiar with OData, OData is an open standard for querying and updating data that relies on common web standard HTTP. Read this OData primer for more details.

The obvious benefits are:

1. SharePoint data can be made available on non-Microsoft platforms and to mobile devices
2. SharePoint can connect and bring in data from any OData sources

Client Programming Options: In SharePoint 2010, there were primarily three ways to access SharePoint data from the client or external environment.

 1. Client side object model(CSOM) – SharePoint offers three different set of APIs, each intended to be used in certain type of client applications. Read the rest of this post »

Consuming OData sources in SharePoint 2013 App step by step

SharePoint 2013  has an out-of-box supports for connecting to OData sources using BCS. You no longer are required to write .Net assembly connector to talk to external OData sources.

1. Open Visual Studio 2012 and create a new SharePoint 2013 App project. This project template is available after installing office developer tools for Visual Studio 2012.

Create App

Select App Settings

2. Choose a name for the app and type in the target URL where you like to deploy the App. Also choose the appropriate hosting option from the drop-down list. For on promise deployment select “SharePoint-Hosted”. You can change the URL later by changing “Site URL” property of the App in Visual Studio.

3.Add an external content type as shown in the snapshot below. It will launch a configuration wizard. Type in OData source URL you wish to connect to and assign it an appropriate name. For this demo purpose, I am using publicly available OData source NorthWind. Read the rest of this post »

31 Days Of OData – Day 5 Addressing Entities In OData

Before we can learn about Addressing Entities in OData, we have to lay the ground work for all OData commanding including queries. We will first detail and demonstrate the Uniform Resource Identifier or URI and then look at a URI for OData.

What is a URI?

An URI is a string that is used to identify a name(URN) or a location to a resource( URL). The URN works like a name of a person or a business name where the URL functions like the physical address of a person or business.

The following are two examples of URI’s$top=2&$orderby=name

As you can the two URI’s are both OData URI’s. The first is called the Service Root URI and the second is an OData query URI that us requesting the first two Products that are associated to Category 1 returned in alphabetical order.

Service Root URI

Every OData call must include the Service Root URI to interact with an OData feed. Think of the Service Root URI as the location of the OData feed. It represents the HTTP listener that will do the work on the behalf of the consumer of the OData feed based on the URI past the root and the HTTP Verb or Command sent.

You may discover that some OData Service Root URI’s do not end with svc. This can be accomplished with routing the request as shown in Ron Jacob’s blob post here.

Resource Path of the OData URI

The Resource Path of OData request URI functions as the resource locator from the OData consumer. It can be a request to any of the following resources of the OData protocol:

  • Single Entity (Baseball Player)
  • Collection of Entities (Baseball Players from a team and year)
  • Entity relationship between multiple Entities (Batting Statistics for a specific Baseball Player)
  • A Property of an Entity (Last Name of a Baseball Player)
  • Service Operation
  • Other resources

Query Options of the OData URI

We will work through many of the Query options during this blog series. Know that all Query Options in OData request URI’s specify three types of information:

  • System Query Options – we will explore this type in detail during this series.
  • Custom Query Options – extension point for server specific information. The Custom Query Option is always passed as a name/value pair.
  • Service Operation Parameters – used to reference a call Service Operations that reside on the OData feed.

Querying Entities

Addressing single or collections of entities located in an OData feed is akin to the FROM clause of a SQL SELECT statement along with JOINs. By allowing associations between Entities an OData request URI can reach far and wide inside the OData feed to request any shape and collection of data.

The following grammar are the rules that cover all entity query scenarios: single Entity, collection of Entities or single Property of Entity.

The areas of the OData request

Collection The Collection will cover either a requested Collection of Entities or from a Service Collection which returns a Collection of Entities.
KeyPredicate A predicate that identifies the value(s) of the key Properties of an Entry. If the Entry has a single key Property the predicate may include only the value of the key Property. If the key is made up of two or more Properties, then its value must be stated using name/value pairs. More precisely, the syntax for a KeyPredicate is shown by the following figure. 

NavPropSingle The name of a Navigation Property defined by the Entry associated with the prior path segment. The Navigation Property must identify a single entity (that is, have a “to 1” relationship).
NavPropCollection Same as NavPropSingle except it must identify a Collection of Entries (that is, have a “to many” relationship).
ComplexType The name of a declared or dynamic Property of the Entry or Complex Type associated with the prior path segment.
Property The name of a declared or dynamic Property of the Entry or Complex Type associated with the prior path segment.


We will be looking at many ways to query and shape the data returned from an OData feed in future blog posts. Stay tuned and hope you are enjoying the series. I am working to catch up also.


Posted in News and Events

31 Days of OData – Day 4 Metadata in OData

OData-logo_bigger_thumb1Let’s go back 15 years ago when I started professionally developing software and using relational databases. The relational database was a great tool to deal with data. No more did we have to use flat files to store our data with tools named Paradox, dBase and other such data management systems. We now had more flexibility to build our solutions and the new architecture pattern Client-Server that was the rage for all developers circa 1996.

Relational databases gave us the SQL language and that in turn allowed the developers of the day to quickly create, read, update and delete (CRUD) data that was stored on the server and build our applications at the client. Life was great (for me at least) because I knew nothing different. If I wanted to learn about a new database, I would get the schema either in a text file that had a set of CREATE SQL calls for all the objects that made up the database. If we were really lucky we received a printed graph of the database that gave the developers a nice graphical layout of the data tables and views with the relationships between the tables and views. It took time to understand the meaning of the database but that is what we did.

In 2007 I experienced a glimpse into the future that shook my world. It was when I started experimenting with a new incubation project from Microsoft called Astoria. I saw it at first as way to get data across HTTP and that excited me. What blew my mind after really learning about it was Metadata. Compared to the time I spent discovering the meaning and shape of the data schema of a relational database that a DBA created and handed to me, Metadata was the bridge into a new frontier.

Let’s step back and take a look at what Metadata is and how it works within OData. Metadata is defined broadly as “Data about Data”. Think of metadata as the Dewey Decimal we learned as kids when we visited the library. The card catalog does not carry the information about the content inside the books but it does describe the books and information that the books contain in a broad level to allow readers to find and locate the books they are interested in on the shelves. Metadata does the same for us as users of the data that the OData feeds allow us to consume.

In OData, the Service Metadata Document allows the consumers of the data provided by the OData feed to understand the Entity Data Model (Day 3 of the series). The Service Metadata Document does not carry any details of the data held within the data repository of the OData feed. It contains the roadmap to the data. In the SOAP world the Service Metadata Document would be the equivalent of the WSDL file. Let’s look at the structure of the Service Metadata Document (in XML) and walk through its map. We will use the Baseball Statistics OData feed found here as our example.

We first need to query the Service Metadata Document from the OData feed. How this is accomplished is my using the $metadata query option at the base of the OData feed as shown below:$metadata

The Service Metadata Document is returned in the payload after the $metadata query and has three parts: the EDMX which is made up of the OData Model and also the Entity Collection.

Code Snippet
  1. <?xmlversion=1.0encoding=UTF8standalone=true?>
  2. <edmx:Edmxxmlns:edmx=>
  3. <edmx:DataServicesm:DataServiceVersion=1.0xmlns:m=>
  4. <Schemaxmlns=>
  5. <EntityTypeName=Allstar>
  6. <Key>
  7. <PropertyRefName=playerID/>
  8. <PropertyRefName=yearID/>
  9. <PropertyRefName=lgID/>
  10. </Key>
  11. <PropertyName=playerIDFixedLength=falseUnicode=trueMaxLength=10Nullable=falseType=Edm.String/>
  12. <PropertyName=yearIDNullable=falseType=Edm.Int16/> <PropertyName=lgIDFixedLength=falseUnicode=trueMaxLength=2Nullable=falseType=Edm.String/>
  13. <NavigationPropertyName=PlayerToRole=PlayerFromRole=AllstarRelationship=BaseballStatsModel.FK_Allstar_Player/>
  14. </EntityType>
  15. <EntityTypeName=AllstarFull>
  16. <Key>
  17. <PropertyRefName=playerID/>
  18. <PropertyRefName=yearID/>
  19. <PropertyRefName=gameNum/>
  20. </Key>
  21. <PropertyName=playerIDFixedLength=falseUnicode=trueMaxLength=10Nullable=falseType=Edm.String/>
  22. <PropertyName=yearIDNullable=falseType=Edm.Int16/> <PropertyName=gameNumNullable=falseType=Edm.Int16/>
  23. <PropertyName=gameIDFixedLength=falseUnicode=trueMaxLength=12Nullable=trueType=Edm.String/>
  24. <PropertyName=teamIDFixedLength=falseUnicode=trueMaxLength=3Nullable=trueType=Edm.String/>
  25. <PropertyName=lgIDFixedLength=falseUnicode=trueMaxLength=2Nullable=trueType=Edm.String/>
  26. <PropertyName=GPNullable=trueType=Edm.Int16/> <PropertyName=startingPosNullable=trueType=Edm.Int16/>
  27. <NavigationPropertyName=PlayerToRole=PlayerFromRole=AllstarFullRelationship=BaseballStatsModel.FK_AllstarFull_Player/>
  28. </EntityType>
  29. <EntityTypeName=PitchingTotals>
  30. <Key>
  31. <PropertyRefName=playerID/>
  32. </Key>
  33. <PropertyName=playerIDFixedLength=falseUnicode=trueMaxLength=10Nullable=falseType=Edm.String/>
  34. <PropertyName=WNullable=trueType=Edm.Int32/> <PropertyName=LNullable=trueType=Edm.Int32/>
  35. <PropertyName=GNullable=trueType=Edm.Int32/> <PropertyName=GSNullable=trueType=Edm.Int32/>
  36. <PropertyName=CGNullable=trueType=Edm.Int32/> <PropertyName=SHONullable=trueType=Edm.Int32/>
  37. <PropertyName=SVNullable=trueType=Edm.Int32/> <PropertyName=IPoutsNullable=trueType=Edm.Int32/>
  38. <PropertyName=HNullable=trueType=Edm.Int32/> <PropertyName=ERNullable=trueType=Edm.Int32/>
  39. <PropertyName=HRNullable=trueType=Edm.Int32/> <PropertyName=BBNullable=trueType=Edm.Int32/>
  40. <PropertyName=SONullable=trueType=Edm.Int32/> <PropertyName=BAOppNullable=trueType=Edm.Double/>
  41. <PropertyName=IBBNullable=trueType=Edm.Int32/> <PropertyName=WPNullable=trueType=Edm.Int32/>
  42. <PropertyName=HBPNullable=trueType=Edm.Int32/> <PropertyName=BKNullable=trueType=Edm.Int32/>
  43. <PropertyName=BFPNullable=trueType=Edm.Int32/> <PropertyName=GFNullable=trueType=Edm.Int32/>
  44. <PropertyName=RNullable=trueType=Edm.Int32/> <PropertyName=SHNullable=trueType=Edm.Int32/>
  45. <PropertyName=SFNullable=trueType=Edm.Int32/> <PropertyName=GIDPNullable=trueType=Edm.Int32/>
  46. </EntityType>
  47. <AssociationName=FK_Allstar_Player>
  48. <EndType=BaseballStatsModel.PlayerMultiplicity=1Role=Player/> <EndType=BaseballStatsModel.AllstarMultiplicity=*Role=Allstar/> <ReferentialConstraint>
  49. <PrincipalRole=Player>
  50. <PropertyRefName=playerID/>
  51. </Principal> <DependentRole=Allstar>
  52. <PropertyRefName=playerID/>
  53. </Dependent>
  54. </ReferentialConstraint>
  55. </Association>
  56. <AssociationName=FK_AllstarFull_Player>
  57. <EndType=BaseballStatsModel.PlayerMultiplicity=1Role=Player/> <EndType=BaseballStatsModel.AllstarFullMultiplicity=*Role=AllstarFull/> <ReferentialConstraint>
  58. <PrincipalRole=Player>
  59. <PropertyRefName=playerID/>
  60. </Principal> <DependentRole=AllstarFull>
  61. <PropertyRefName=playerID/>
  62. </Dependent>
  63. </ReferentialConstraint>
  64. </Association>
  65. <AssociationName=FK_TeamsHalf_Teams>
  66. <EndType=BaseballStatsModel.TeamMultiplicity=1Role=Team/> <EndType=BaseballStatsModel.TeamHalfMultiplicity=*Role=TeamHalf/> <ReferentialConstraint>
  67. <PrincipalRole=Team>
  68. <PropertyRefName=yearID/>
  69. <PropertyRefName=lgID/>
  70. <PropertyRefName=teamID/>
  71. </Principal> <DependentRole=TeamHalf>
  72. <PropertyRefName=yearID/>
  73. <PropertyRefName=lgID/>
  74. <PropertyRefName=teamID/>
  75. </Dependent>
  76. </ReferentialConstraint>
  77. </Association>
  78. </Schema>
  79. <Schemaxmlns=>
  80. <EntityContainerName=BaseballStatsEntitiesxmlns:p7=>
  81. <EntitySetName=AllstarEntityType=BaseballStatsModel.Allstar/>
  82. <EntitySetName=AllstarFullEntityType=BaseballStatsModel.AllstarFull/>
  83. <EntitySetName=PitchingTotalsEntityType=BaseballStatsModel.PitchingTotals/>
  84. <AssociationSetName=FK_Allstar_PlayerAssociation=BaseballStatsModel.FK_Allstar_Player>
  85. <EndRole=PlayerEntitySet=Player/>
  86. <EndRole=AllstarEntitySet=Allstar/>
  87. </AssociationSet>
  88. <AssociationSetName=FK_AllstarFull_PlayerAssociation=BaseballStatsModel.FK_AllstarFull_Player>
  89. <EndRole=PlayerEntitySet=Player/>
  90. <EndRole=AllstarFullEntitySet=AllstarFull/>
  91. </AssociationSet>
  92. <AssociationSetName=FK_TeamsHalf_TeamsAssociation=BaseballStatsModel.FK_TeamsHalf_Teams>
  93. <EndRole=TeamEntitySet=Team/>
  94. <EndRole=TeamHalfEntitySet=TeamHalf/>
  95. </AssociationSet>
  96. </EntityContainer>
  97. </Schema>
  98. </edmx:DataServices>
  99. </edmx:Edmx>

OData Model

Read the rest of this post »


Posted in News and Events

31 Days of OData – Day 3 OData Entity Data Model

OData-logo_biggerFrom Day 2 of the series, we looked at data types that are present in the OData protocol. These data types allow for the richness of the data experience. Next we will look at taking these data types and crafting the entities that make up the OData feed.

An OData feed is very much like a database with tables, foreign keys and stored procedures. The data from an OData feed does not have to originate in a relational database but this is the first and most important type of data repository that OData can represent. The OData’s Entity Data Model (EDM) is simple but elegant in its representation of the data. It is designed to handle the data but also the relationships between entities that allow for the rich data experience we experience.

The Roadmap of the EDM

Just like a roadmap the EDM acts as a guide that allows us to travel the OData feed’s paths. It furnishes us the collections of entities and all details needed to understand the entities within its map. The EDM also gives us the paths or associations between the unique Entities of the OData feed. The ability to navigate easily without knowing much about the layout of the OData land is where OData gives us the freedom to have the Data Experiences (DX) we need for today’s solutions and consumer expectations.

The Entitles in an OData feed represents a specific type of data or Entity Type. The Entity Types of an OData feed could simulate some real world item, concept or idea such as a Book, College Course or Business Plan. The Entity Type contains properties that must adhere to the data types allowed and provided by the OData protocol or be of a Complex Type (explained later). To exist in the OData protocol, the Entity Type must be unique and so must have a unique identifier that allow for the Entities of that Entity Type to be located and used within the OData Feed. The Entity Key can be composed of one or more Entity properties and will be a unique property for the Entity Type. Most Entity Types will have a single property but that is not a requirement. An example of a multiple property Entity Type key is on my baseball stats OData feed and the Batting Entity Type.

The Batting Entity Type in my baseball stats OData feed is comprised of the following properties:

  • playerID – the Player Entity Type’s Key
  • yearID – the year of the baseball season
  • stint – baseball players could be traded and traded back to a team in the same season so needs to be tracked
  • teamID – the team the Player played for in the stint
  • lgID – the league of the team the player played for in the stint

As you can see OData can handle complex or composite Keys and allow for almost anything we give it. The collection of Entities is grouped in an Entity Set within the OData feed.

The following is an example of an Entity Type from the baseball statistics OData feed.

The OData feed can also contain Associations that define the connections (or roads from our earlier analogy) between the Entity Type and another Entity Type. An example would be the Association between a Baseball Player and his Batting Statistics. An Entity Type’s collection of Associations is called an Association Set and along with the Entity Set is assembled into an Entity Container. The Link or Navigation Property that makes up the Entity Type must act on behalf of a defined Association in the OData feed. The following is an example of what the Entity Container looks when querying the Service Metadata Document.

A special type of structured types that can be in an OData feed is a Complex Type. The Complex Type is a collection of properties without a unique Key. This type can only be contained within an Entity Type as a property or live outside of all Entity Types as temporary data.

The last item that can be represented in the Entity Data Model is a Service Operation. We will look at the Service Operation later in the series. For now understand that Service Operations are functions that can be called on an OData feed. A Service Operation behaves similar to the Stored Procedures in a relational database.

We have looked at the Entity Data Model and what defines it in the world of OData. This will allow us to lay down a foundation for future blog posts in this series to explain the behaviors and results that we expect from our OData feeds.


Posted in News and Events

31 Days of OData – Day 2 Data Types of OData

OData-logo_biggerSince data is the basis for all OData feeds it is natural to see then that describing the data that represents the types Entities with in the feed is important. It is not only important for the data but also for the metadata that plays a significant role in the OData protocol.

The OData protocol is a very structured standard and with it also come a set of primitive data types. Each data type has a distinct set of properties themselves and we will look at each and understand those characteristics. Let’s dig into the list shall we?

What are the Data Types for OData?

I will give the list of primitive data types that can be used with the OData protocol and additionally I will give some of the characteristics for each type. We all should know most of these data types but it will be a good refresher.

Primitive Types





Represents the absence of a value




Represent fixed- or variable- length binary data

X and binary are case sensitive. Spaces are not allowed between binary and the quoted portion. Spaces are not allowed between X and the quoted portion. Odd pairs of hex digits are not allowed.



Represents the mathematical concept of binary-valued logic


Example 1: true

Example 2: false


Unsigned 8-bit integer value




Represents date and time with values ranging from 12:00:00 midnight, January 1, 1753 A.D. through 11:59:59 P.M, December 9999 A.D.

Spaces are not allowed between datetime and quoted portion. datetime is case-insensitive



Represents numeric values with fixed precision and scale. This type can describe a numeric value ranging from negative 10^255 + 1 to positive 10^255 -1




Represents a floating point number with 15 digits precision that can represent values with approximate range of ± 2.23e -308 through ± 1.79e +308


Example 1: 1E+10 Example 2: 2.029

Example 3: 2.0


Represents a floating point number with 7 digits precision that can represent values with approximate range of ± 1.18e -38 through ± 3.40e +38




Represents a 16-byte (128-bit) unique identifier value




Represents a signed 16-bit integer value


Example 1: 16

Example 2: -16


Represents a signed 32-bit integer value


Example 1: 32

Example 2: -32


Represents a signed 64-bit integer value


Example 1: 64L

Example 2: -64L


Represents a signed 8-bit integer value


Example 1: 8

Example 2: -8


Represents fixed- or variable-length character data


Example 1: ‘Hello OData’


Represents the time of day with values ranging from 0:00:00.x to 23:59:59.y, where x and y depend upon the precision


Example 1: 13:20:00


Represents date and time as an Offset in minutes from GMT, with values ranging from 12:00:00 midnight, January 1, 1753 A.D. through 11:59:59 P.M, December 9999 A.D


Where do the Data Types for OData come from?

Where do the datatypes for OData originate is a great look at the history of OData and what other products helped shape the protocol. OData originated with Microsoft so first we will look at where most data resides when developing solutions on the Microsoft stack of tools and technologies: SQL Server. When the OData protocol was announced back in 2010 most of the data types used in Microsoft SQL Server 2008 could be used to represent data in an OData feed. It would only seem logical that a technology that was developed with an organization would be shaped and influenced by the tools at hand and OData is no exception.

But that is just the start. We must also look at the Entity Framework as another key influencer in the maturation of the OData protocol. If you notice in the table above the list of the data types all have the prefix “Edm.” associated. That comes from the Entity Framework to mean “Entity Data Model”. Why is this so? It could be that other data types will be allowed at some time and that some with the same literal name could be brought into the OData protocol specification but with slightly different characteristics. If that happened these new set of primitives could conflict with the existing data types (example could be datatypes from Oracle).

The OData team was smart enough to allow for this and started using prefixes that could distinguish possibly a different representation of a string by two different database products (example could be the maximum fixed length of a string). These new data types could be given their own prefix and happily live side by side with the original data types from SQL Server and Entity Framework.

What about Spatial Data Types?

The Spatial data types that first were brought to the Microsoft world in SQL Server 2008 are a new exciting feature of both the Entity Framework 4.0 product but also for OData. These new data types are so exciting that I will be spending an entire blog post covering these later in the month. I will update and link this blog post chapter to that future post so stay tuned.


Posted in News and Events

31 Days of OData – Day 1 Background of OData

OData-logo_biggerWhat is the Open Data Protocol?

The official statement for Open Data Protocol (OData) is that is a Web protocol for querying and updating data that provides a way to unlock your data and free it from silos that exist in applications today. Really what that means is that we can select, save, delete and update data from our applications just like we have been against SQL databases for years. The benefit is the ease of setting up and libraries that Microsoft has created for us the developers of Windows Phone 7 Mango apps. The benefit comes from the fact that OData has a standard that allows a clear understanding of the data due to the metadata from the feed.

Behind the scenes, we send OData requests to a web server that has the OData feed through HTTP calls using the protocol for OData. You can read more about OData here.

Where did OData come from?

OData started back in 2007 at the second Microsoft MIX conference. The announcement was an incubation project codenamed Astoria. The purpose of Project Astoria was to find a way to transport data across HTTP in order to architect and develop web based solutions more efficiently. Not until after the project had time to incubate did the OData see patterns occurring that led them to see the vision of the Open Data Protocol. The next big milestone was the 2010 Microsoft MIX Conference where OData was officially announced and proclaimed to the world as a new way to handle data. The rest is history.

Building OData on the Shoulders of Web Protocols

One of the great features of the OData protocol is the use of existing and mature standards. The OData team I feel did a great job identifying and using existing technologies to build upon. The following are the technologies, standards and/or existing protocols that were used in the development of OData:

Really nothing much can be done on the Internet without HTTP so why wouldn’t OData use HTTP for its transport? Most web developers know about HTTP (or should know) so I will not dull you with details.

Most people know that Atom is used with RSS feeds to aggregate the content to others through HTTP. What you may not have known is how similar a RSS feed is to a database.

    • The RSS Feed is a collection of blog posts which can be seen as a Database and a table. Databases I know contain multiple tables so that is that are where OData builds it beyond Atom where it has multiple collections of typed Entities.
    • A Blog post inside a RSS feed is similar to a record in a Database table. The blog post has properties like Title, Body and Published Date. These properties can be seen as columns of a database table.
  • REST (Representational state transfer)

OData was developed to follow the definition of REST. A RESTful web service or RESTful web API is a web service implemented through HTTP and the principles of REST. It is a collection of resources, with four defined aspects:

    • the base URI for the web service, such as
    • the Internet media type of the data supported by the web service. This is often JSON, XML or YAML but can be any other valid Internet media type.
    • the set of operations supported by the web service using HTTP methods (e.g., GET, PUT, POST, or DELETE).
    • The API must be hypertext driven.

What will come with the OData Blog Series?

I hope this blog series will give the community and my readers a new perspective of the OData protocol. We will cover in depth the different areas of the protocols such as datatypes, query options and vocabularies. At the end of the series I hope to have answered many of your questions and also started getting you to identify areas and solutions where OData could add benefits to your solutions, services and products.

I also hope it will raise more questions about OData that I or others can answer and generate new ideas that can add more appeal and features to this exciting protocol.

Being a Data Experience (DX) Expert

At the end of the blog series I hope I will also make more of you Data Experience Experts. That is a new term I think I coined some time ago. What is a Data Experience Expert? Well User Experience is defined in Wikipedia as:

User experience (UX) is the way a person feels about using a product, system or service. User experience highlights the experiential, affective, meaningful and valuable aspects of human-computer interaction and product ownership, but it also includes a person’s perceptions of the practical aspects such as utility, ease of use and efficiency of the system.

Based on the UX definition we could define DX as:

Data experience (DX) is the way a person feels about using data. Data experience highlights the experiential, affective, meaningful and valuable aspects of data interchanges, but it also includes a person’s perceptions of the practical aspects such as ease of use and efficiency of the data and data transportation.

I do hope you will find this definition valuable as you gain more experience with OData and other Data technologies to also pin the title of DX expert to your resume.


Posted in News and Events