RESTful服务描述
据我了解，我需要使用 WADL 来描述 RESTful Web 服务。尽管如此，我在相关帖子中看到了很多答案，其中用户强烈反对使用 WADL。
WADL 的缺点是什么？有其他解决方案吗？
From what I understand, I need to use WADL to describe a RESTful web service. Still, I have read many answers in relevant posts, where users are strongly opposed the use of WADL.
What are the disadvantages of WADL? Is there any alternative solution?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
HTTP 规范告诉您如何检索和更新资源。资源由 URI 标识，并且应该链接在一起，因此所有数据都应该可以从服务根 url 中发现，就像网站上的页面一样。剩下的就是记录您通过网络传输的媒体类型。
如果您采用这种方法并且跨服务重用媒体类型，那么您只需记录媒体类型一次，它将适用于所有服务。
完成这些步骤后，WADL 就不再需要记录任何内容了。
如果您想要执行 REST，则不能使用 WADL 来编码生成客户端，因为这会在客户端和服务器之间创建紧密耦合。如果您同意，那很好，但要意识到您没有进行 REST，因此不会意识到 REST 的一些好处。
The HTTP spec tells you how to retrieve and update resources. Resources are identified by URIs and should be linked together, so all data should be discoverable from the service root url, just like pages on a web site. What that leaves is for you to document the media-types that you are transferring across the wire.
If you take this approach and you reuse media-types across services then you only need to document the media type once and it will be applicable for all services.
Once you have done those steps there is really nothing left for WADL to document.
If you want to do REST you cannot use WADL to code generate clients, as that creates a tight coupling between client and server. If that's ok with you, fine, but just realize that you are not doing REST and therefore will not realize some of the benefits of REST.