Resource Format
Overview
The goal of this document is to define extra requirements on the data returned by the RESTful service to enable reporting, details about resources in specific domain will be described in specification for each domain separately.
Identifying properties
Each property should be uniquely identifiable.
To be more concrete, following are two different ways to organize data, and their implications based on the above assumption.
1. Option 1
If the data is represented in a generic way like this:
<attribute>
<name>att1</name>
<value>value1</value>
</attribute>
<attribute>
<name>att2</name>
<value>value2</value>
</attribute>
We can identify "name" and "value" of the "attribute", we will get a list of generic attributes like this (logically):
name |
value |
att1 |
value1 |
att2 |
value2 |
The benefit is, we deal with the attributes in a generic way, this allow us to support new, custom attributes without changes. The disadvantage is, we can't deal with each attribute using specific logic since we can't tell one attribute from the other.
2. Option 2
If the data is like this:
<att1>value1</att1>
<att2>value2</att2>
Then we can identify "att1" and "att2", we will get specific attributes like this (logically)
The benefit is, we can deal with each attribute with specific logic. The disadvantage is, we can't support new, custom attributes without changes.
Extracting data
The reporting consumer should be able to extract real content for the properties from the resultset directly. That means, the service provider should return real content for properties in the resultset and the reporting consumer shouldn't be forced to follow URLs to retrieve real content for properties.
Identifying resources
Each resource MUST be globally uniquely identifiable.
Choices for identifier:
1. absolute URI reference
... (other choices?)
Comments
Add your comments here:
--
XiangDongHu - 03 Nov 2009