OData规范很长。即使是"OData Core"文档也相当长。
那么,简要总结一下只读OData发布者至少需要实现什么呢?
我开始。OData服务提供一个HTTP端点,该端点:
- 必须理解"
Accept
"标题 - MUST支持Content-Type标头,并且MUST支持ATOM格式(可选JSON)
- 可将服务文档(集合列表)返回给
GET /
(10.1.1)- 如果ATOM(AtomPub?)格式,则层次结构为
service/workspace/collection/title
- 如果ATOM(AtomPub?)格式,则层次结构为
- 必须向
GET /Customers
(10.2)等请求返回集合说明- 如果是ATOM,则层次结构为
feed/entry/content
- 如果是ATOM,则层次结构为
- 必须向
GET /Customers(3)
(10.2.1)等请求返回单个实体的描述 - 对于
GET /Customers(3)/Name
(10.2.2)等请求,可能会返回单个实体的单个属性 - 必须提供包装在EDMX文档中的CSDL模式描述(10.1.2)
- 应在
/$metadata
上提供
- 应在
- 可能支持任何这些查询(10.2.3)
- 筛选器(返回的限制行):
Products?$filter=Price lt 10.00
- 选择(返回限制字段):
Products?$select=Rating,ReleaseDate
- 订购人:
Products?$orderby=ReleaseDate asc, Rating desc
- 顶部,跳过:
Products?$top=5&$skip=2
- InlineCount(包括实体计数):
Products?$inlinecount=allpages
- 筛选器(返回的限制行):
- 必须(?)提供实体的关系列表(10.2.4):
Products(0)/$links/Orders
- 必须提供实体计数(10.2.5):
Products/$count
- 可能支持带有
$format
说明符的其他格式(10.2.3.7)
当返回ATOM提要(例如集合)时,它需要符合一些OData约定:http://www.odata.org/documentation/odata-v3-documentation/atom-format/例如:
- 使用的类型为"
edm:String
"等 link
元素被大量使用content
元素要么包含内联内容(如文本数据),要么链接到具有src=
属性的内容(如图像、二进制文件)
当返回JSON提要时,它同样遵循某些规则:
- http://www.odata.org/documentation/odata-v3-documentation/json-verbose-format/
鼓励URL遵循此方案:
- http://www.odata.org/documentation/odata-v3-documentation/url-conventions/