自建营销型企业网站,wordpress 游戏 模板下载地址,wordpress微博登陆不了,代发qq群发广告推广What – OData是什么#xff1f;
OData - Open Data Protocol#xff0c;是一个设计和使用RESTful API的标准。REST本身只是一个构建web服务的思想和理念#xff0c;其没有规定一个统一的标准来限制开发人员该如何设计RESTful API。其实我们实际开发中的确也没有遵循某个统…What – OData是什么
OData - Open Data Protocol是一个设计和使用RESTful API的标准。REST本身只是一个构建web服务的思想和理念其没有规定一个统一的标准来限制开发人员该如何设计RESTful API。其实我们实际开发中的确也没有遵循某个统一的标准去设计WebAPI。因为大多数场景下遵循一个统一的标准并不是必要的。但在某些场景下有这样一个标准却能带来很大的好处。
OData的理想是, 无论哪个组织构建的RESTful API只要其符合OData标准。其他组织就可以按照OData标准中定义的方式去使用这个API获取/修改资源。这个可以类比SQL标准之于RDBMS关系。无论什么关系型数据库如果其声称支持SQL 标准任何人就可以使用标准SQL查询语句来查询数据。
标准化的另一个好处可以将Odata协议实现到一个通用的类库中通过这个类库去创建和访问RESTful API可以减少开发人员的工作量。官网上有很多这样的组件。 Who - 谁发布了OData
该标准由微软发起前三个版本1.0、2.0、3.0都是微软开放标准。 When - 什么时候成为了工业标准
第四个版本4.0于2014年3月17日在OASIS投票通过成为开放工业标准 Why – 为什么需要OData
OData是一个协议一个标准。所以这个问题等同于为什么我们需要协议。类比TCP协议就可以理解一般。假设你开发的组件必须要和某个第三方组件通信如果第三方组件不支持TCP而只支持其内部开发的一个私有协议你就肯定头大了你必须在你的组件里单独为其实现这个私有协议。如果大家都支持TCP协议不就省事了么。这就是标准协议的作用协议和标准用于制定一个统一通用的规则。 我们只需要按照这个协议或标准生产组件那么这个组件就可以方便的和其他组件集成/协作。而无须根据其他组件的私有标准定制化组件。 前面说到Rest只是一种设计Web服务的思想不是一种标准化的协议。正由于缺乏标准化从而导致各家公布的Restful API 统一通用方面的欠缺。OData就是为弥补这种欠缺而被提出来的标准协议。 下面全是延伸阅读可略过。
Web服务有两种实现方式一是SOAP协议方式二是REST方式。SOAP是一套完整的实现Web服务的解决方案。这里有必要先简单了解SOAP方式的Web服务然后对比SOAP方式我们会发现REST方式欠缺了什么。 SOAP方式的Web服务中的Web服务描述语言WSDL和简单对象访问协议SOAP一起构成了SOAP方式下的Web服务的结构单元。客户端通过WSDL可以了解Web服务公开了那些可以被执行的方法以及Web服务可以发送或接收的消息格式解决了公布访问资源方法的问题。客户端按照SOAP将调用位于远程系统上的服务所需信息序列化为消息解决了如何调用远程方法的问题。注意WSDL描述的服务以及SOAP消息都是符合统一标准的都是机器可读的.
WSDL基于XML格式用来描述Web服务。WSDL文档可以看成是客户端和服务器之间的一个协约。使用WSDL工具你可以自动处理这个过程几乎不用手工编写代码就能够让应用程序整合新的服务。因此WSDL是Web服务体系结构的基础因为它提供了一个通用语言用来描述服务和整合这些服务的平台。
SOAP本身提供了与Web服务交换信息的方法。SOAP是序列化调用位于远程系统上的服务所需信息的标准方法这些信息可以使用一种远程系统能够读懂的格式通过网络发送到远程系统而不必关心远程系统运行于何种平台或者使用何种语言编写。SOAP以XML格式提供了一个简单、轻量的用于在分散或分布环境中交换结构化和类型信息的机制。实际上它通过提供一个有标准组件的包模型和在模块中编码数据的机制定义了一个简单的表示应用程序语义的机制。 对照SOAP方式的Web服务REST中没有用于描述资源服务列表资源元数据的类似于WSDL的东东。所以有人在2009年提出了一个标准WADL去描述REST方式的Web服务但至今没有被标准化。个人认为使用WSDL/WADL去描述REST方式的Web服务太别扭这是典型的RPC思路而REST是一种把服务抽象为资源的架构思想。用描述RPC的WSDL去描述REST方式的Web服务并不合适。我们需要其他策略去代替WSDL实现“公布访问资源方法的问题”。
由于没有类似于SOAP的权威性协议作为规范因此各个网站的REST实现都自有一套也正是因为这种各自实现的情况在性能和可用性上会大大高于SOAP发布的web service但细节方面有太多没有约束的地方其统一通用方面远远不及SOAP。
举个例子假设A组织B组织都实现了Restful API来通过工号查询人员信息因为没有统一的规范。
A的API 可能是这样http://A/api/person/001
B的API 可能是这样http://A/api/person/id001
第三方客户端在实现远程调用的时候就必须考虑这些API的差异分别查看AB的API文档。
如果有个权威性协议作为规范做指导规定这个API应该实现成下面这样那么第三方客户端也只需按照这个标准去调用远程API而不用查看AB的API文档
http://A/api/person/{001}
解释了这么多就是为了引出OData是这样的一个设计和使用Restful API 的权威性协议. OData定义了一些标准规则像一个接口定义一堆方法一样实现Restful API时候必须实现这些标准规则就像实现一个接口必须实现其所有方法一样。第三方就可以根据Odata协议定义的规则去访问Restful API。 Where –什么样的场景下可以考虑使用OData
并不是说你创建的所有RESTful API都需要符合OData协议。只有在需要Open Data开放数据给其他组织时候才有必要按照OData协议设计RESTful API。这里的Open Data是指开放数据给第三方使用并且你并不知道谁是第三方。比如博客园的RSS谁订阅了RSS博客园是不清楚的。如果你的数据只被你自家公司的客户端使用 OData就是一个可选项你完全有理由不按照OData规范去设计RESTful API。 How – 如何使用OData
首先看一下C#客户端调用符合OData标准的WebApi是多么的方便官网http://www.odata.org/上也有js的类库。
第一步通过Nuget安装OData Client for .Net包。 第二步安装VS插件OData v4 Client Code Generator。 第三步假设存在一个可用的WebApi后面介绍如何创建 - http://localhost:33189/Odata. 我们修改代码模板中的MetadataDocumentUri如下 然后保存。T4会访问http://localhost:33189/Odata获得资源的元数据然后根据元数据生成资源对应的C#类。T4可以怎么做是因为WebApi是按照OData的标准去公布资源列表和资源的元数据。 第四步在我们的代码中就可以操作CLR对象来消费远程的webAPI了。体验到Odata标准的力量了吧。 接下来看一下C#服务端如何实现上面客户端需要调用的OData的WebAPI有两种方式有点细微的差别。
第一步创建一个空的WebApi项目。
第二步: 通过Nuget引入EF6 和 WebApi 2.2 for OData v4.0. 如下图。 第三步创建Entity和DbContext类以及配置数据库连接。并通过enable migration完成数据库的创建可在Configuration的seed的方法中添加一些初始化的数据。 第四步配置WebApiConfig如下 第五步创建ProductsController View Code
第六步F5运行接着客户端就可以调用了。可以通过访问http://localhost:#/OData/ 和 http://localhost:#/OData/$metadata 看看resource list 和元数据长什么样。 另外我们可以通过VS的OData Controller模板来创建webAPIController如下。注意使用这种方式创建webAPIController时不可以导入WebApi 2.2 for OData v4.0这个类库否则会出现dll冲突。 分类: C#
