为了描述 RESTful,我们可以说每个资源都有自己的 URI。使用 HTTP GET、POST、PUT 和 DELETE,我们可以对这些资源进行操作。所有资源都具有代表性。任何想要使用我们资源的人都可以通过浏览器或 REST 客户端进行操作。
这就是 RESTful 架构的主要思想。这种架构允许互联网上的服务。那么为什么这个架构需要WADL呢?WADL 提供了标准 HTTP 不提供的什么?为什么需要存在 WADL?
The purpose of WADL is to define a contract. Contract specifies how one party can call another.
When you create a web application from scratch, you don't need contract and WADL.
When you integrate your system with the other system and you can communicate clearly with their development team, you don't need contract and WADL (because you can make a phone call to make things clear).
However when you integrate a complex enterprise system with several others complex enterprise systems maintained by several different companies (or federal institutions), then believe me you want to have a communication contract defined as strictly as possible. Then you need WADL or Open Specification. Need it badly.
People with weak enterprise background tend to see entire IT as a collection of separated web applications developed independently. But enterprise reality is sometimes tough. Sometimes you can't even call or write to the people developing the application you have to integrate with. Sometimes you communicate with a legacy application that is no longer maintained--it just runs and you need to figure out how to communicate with it properly. In such conditions you need a contract because it saves your ass.
Actually client generation is the minor feature of the contract definition. It's just a toy. Contract enforces bad communicators to communicate integration rules clearly. This is the main reason to use WADL or Open Specification or whatever.
使用 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 allows you to generate code, tests and documentation. Actually there are few very useful tools utilizing WADL, you can see some examples here. The problem with the "pure" REST, as described in Fielding's dissertation, is writing clients supporting Hypermedia (imagine writing Java Swing-based client application for example). With WADL this task is completely automated, and it's a huge advantage in my view. Testing becomes a way easier too.
Before I give my explanation, let me say that most pure REST extremists will deride it to the ends of the earth. I don't agree with them, as i'd rather get something done, but just so you know.
WADL is a description of a web service API, a little like WSDL is for SOAP type web services, that is designed to be more in tune with RESTful interfaces (something WSDL is poor at).
It's primary usage in my experience is to allow you to generate client code that can call the service (handy if it's a very large API, which literally saves hours of work). It also serves the purpose of documenting a REST-like interface.
When you want to expose the REST services ,the best way is to generate WADL and share with consumer(similar to WSDL in SOAP based web services).WADL is used to describe service all in on place.
WADL is not necessary to use. But, If you are working with complex existing application and you want to implement REST service call by replacing the EJB/SOAP service call, Then it is very safe and good practice that you use WADL. By using WADL generate client side java stubs you will be in sync with the service.
You can generate client side java stub using WADL file with help of wadl2java maven plugin.