Previous Page Arrow Next Page Arrow

7.4 Read on Property URL

SData supports read operations on property URLs. For example, the following read will return the contact of a sales order resource:

GET /sdata/myApp/myContract/-/salesOrders('43660')/contact

This read returns the following response:

200 OK
Content-Type: application/atom+xml; type=entry
ETag: gJaGtgHyuAwW6jMI4i0njA
<entry xmlns:sdata="" 
  <title>Contact 216</title>

  <link rel="self" type="application/atom+xml; type=entry" title="Refresh" 
        href="'216')" />
  <link rel="edit" type="application/atom+xml; type=entry" title="Edit" 
        href="'216')" />
  <link rel="" 
        type="application/xml" title="Schema" 
        href="$schema?version=5" />
  <link rel="" 
        type="application/atom+xml; type=entry" title="Template" 
        href="$template" />
  <link rel="" 
        type="application/atom+xml; type=entry" title="Post" 
        href="" />
  <link rel="" 
        type="application/atom+xml; type=feed" title="Service" 
        href="$service" />

  <category scheme="" 
            term="resource" label="Resource"/>

  <content>John Smith</content>
    <contact xmlns=""

This feature is restricted to properties that represent relationships (properties that carry an sme:relationship attribute in the schema).

Relationship properties that support this feature MUST be flagged with canGet=”true” in the schema.

SData uses the sme:isCollection attribute of the property to decide whether a GET operations on a property URL is a query that returns a feed or a read that returns a single entry. In the example, the contact property has sme:isCollection set to false and the GET operation returns an entry. In the Queries on Property URLs example, the orderLines property sme:isCollection is set to true and the GET operation returns a feed.

The fact that this read is performed on a property URL (salesOrders(‘43660’)/contact) rather than a resource URL (contacts(‘216’)) does not make any difference. All the mechanisms described in this section (caching, payload control) also apply to property URLs.

As contacts are exposed as a discrete resource kind, the id of the returned entry is its primary id contacts(‘216’), not the hierarchical URL that was submitted (salesOrders(‘43660’)/contact). This set up is recommended when the related resources are exposed as a separate resource kind and have such a primary URL. The other form (hierarchical URL) is allowed when the related resources don’t have a primary URL (when their resource kind is flagged as sme:canGet=”false”).

SData providers SHOULD support read operations on property URLs. They MUST support them on all the properties that are flagged with sme:canGet="true" and sme:isCollection="false" in the schema.

Previous Page Arrow Next Page Arrow