为了描述RESTful,我们可以说每个资源都有自己的URI.使用HTTP GET,POST,PUT和DELETE,我们可以对这些资源进行操作.所有资源都具有代表性.谁想要使用我们的资源可以通过浏览器或REST客户端来实现.
这是RESTful架构的主要思想.这种架构允许互联网上的服务.那么为什么这个架构需要WADL呢？WADL提供的标准HTTP不是什么？为什么WADL需要存在？
WADL的目的是定义合同.合同规定了一方如何打电话给另一方.
从头开始创建Web应用程序时,您不需要合同和WADL.
当您将系统与其他系统集成并且您可以与他们的开发团队清楚地沟通时,您不需要合同和WADL(因为您可以拨打电话以清楚地说明).
但是,当您将复杂的企业系统与其他几个由不同公司(或联邦机构)维护的复杂企业系统集成时,请相信我,您希望尽可能严格地定义通信合同.然后你需要WADL或Open Specification.需要它很糟糕.
企业背景薄弱的人倾向于将整个IT视为独立开发的独立Web应用程序的集合.但企业现实有时很艰难.有时,您甚至无法打电话或写信给开发您必须集成的应用程序的人员.有时您与不再维护的遗留应用程序进行通信 - 它只是运行,您需要弄清楚如何正确地与它进行通信.在这样的条件下,你需要一个合同,因为这样可以节省你的屁股.
实际上,客户端生成是合同定义的次要特征.这只是一个玩具.合同强制执行不良沟通者清楚地传达集成规则.这是使用WADL或Open Specification等的主要原因.
使用WADL意味着您可能非常慷慨地实际定义您来回传递的数据/文档.假设您传递了一些XML片段,它们实际上可能是已定义架构的一部分.
是否使用DL生成代码对我来说并不是很重要.在我的主观意见中,重要的是在业务合作伙伴之间就接口达成正式协议非常重要.即使传递的内容是显而易见的,如果有人更改以前的界面,也有助于确定谁必须在以后解决问题.
数据格式与动词名称一样是界面的一部分.
WADL吸引来自SOAP世界的人们,在这里人们常常使用代码生成器来创建基于WSDL的客户端代码.我不认为该机制在REST中有用,因为它创建了耦合到服务器端点的客户端代码.
我相信如果您正确定义媒体类型并在这些媒体类型中使用超媒体,那么就没有必要使用WADL.可用端点的描述包含在媒体类型定义本身中.如果您现在对自己说,但application/xml不包含任何有关可用超链接的信息,那么我说BINGO.这就是为什么我认为application/xml和application/json不适合用于REST的媒体类型.我不是说不使用XML或JSON,只是不要使用通用媒体类型名称.
WADL的另一个吸引力是为了记录REST服务.不幸的是,当WADL尝试记录服务器端端点时,它会导致开发人员走错路.记录REST服务应主要关注媒体类型.客户端开发人员应该能够在不知道除根URL之外的任何URL的情况下编写REST客户端.
WADL允许您生成代码,测试和文档.实际上使用WADL的工具很少,你可以在这里看到一些例子.如Fielding的论文所述,"纯"REST的问题在于编写支持Hypermedia的客户端(例如,想象一下编写基于Java Swing的客户端应用程序).使用WADL,这项任务是完全自动化的,在我看来这是一个巨大的优势.测试变得更容易.
在我解释之前,让我说大多数纯粹的REST极端主义者会将它贬低到地球的尽头.我不同意他们,因为我宁愿完成某些事情,但只是你知道.
WADL是Web服务API的描述,有点像WSDL用于SOAP类型的Web服务,它被设计为更符合RESTful接口(WSDL很差).
根据我的经验,它的主要用途是允许您生成可以调用服务的客户端代码(如果它是一个非常大的API,可以方便地节省数小时的工作).它还用于记录类似REST的界面.
REST没有指定WADL.
京公网安备 11010802040832号 | 京ICP备19059560号-6 