您能否帮助阐明有关RESTful服务和代码生成的一些观点？

REST可以非常微妙。我也做过很多阅读，每隔一段时间我就回过头来阅读菲尔丁论文的第5章，每次都能找到更多的洞察力。它第一次就像泥一样清晰（尽管有些事情是有意义的）但是只有在我尝试应用原理并使用构建块时才会变得更好。 所以，根据我目前的理解，让我们试一试： 为什么RESTafarians不喜欢代码生成？ 简短的回答：如果你使用超媒体（+链接）没有必要。 上下文：在客户端和服务器之间明确定义合同（WADL）并不会减少耦合：如果更改服务器，则客户端会中断，您需要重新生成代码。 （恕我直言，甚至自动化它只是对潜在耦合问题的补丁）。 REST可以帮助您在不同级别上解耦。超媒体可发现性是开始的商品之一。另见相关概念HATEOAS 我们让客户“发现”我们正在运营的资源可以做什么，而不是之前定义合同。我们加载资源，检查“命名链接”，然后按照这些链接或填写表单（或表单链接）来更新资源。服务器通过基于状态建议的选项充当客户端的指南。 （想想业务流程/工作流程/行为）。如果我们使用合同，我们需要知道这个“带外”信息并更新合同。 如果我们使用带有链接的超媒体，就不需要“单独的合同”。一切都包含在超媒体中 - 为什么要设计一个单独的文档？甚至URI模板都是带外信息，但如果保持简单可以像Amazon S3一样工作。 是的，我们在转移表示（超媒体）时仍需要一个共同点，因此我们定义您自己的媒体类型或使用广泛接受的媒体类型，如Atom或Micro-formats。因此，在基本构建块（链接+表单+数据 - 超媒体）的约束下，我们通过将带外信息保持在最低限度来减少耦合。 首先，看起来超媒体不会改变变化的影响:)：但是，存在微妙的差异。首先，如果我有一个WADL，我需要更新另一个文档并部署/分发。使用纯超媒体，因为它是嵌入式的，所以没有任何影响。 （想象一下，通过一系列复杂的系统交织，会发生变化）。根据您的示例，具有FirstName + LastName并且添加FullName并不会真正影响客户端，但删除First + Last并替换为FullName即使在超媒体中也是如此。 作为旁注：REST统一接口（动词约束 - GET，PUT，POST，DELETE +其他动词）将实现与服务分离。 也许我完全错了，但另一种可能性可能是对代码生成的“心理反击”：WADL让人想到“传统的Web服务（WSDL + SOAP）”/ RPC中的WSDL（契约）部分，它违背了REST。在REST状态通过超媒体而不是RPC传输，这是在服务器上更新状态的方法调用。 免责声明：我没有详细完成参考文章，但我确实给出了一些很好的观点。     

我已经在API项目上工作了很长一段时间。 回答你的第一个问题。 是，如果服务返回值更改（例如：名字和姓氏变为全名），您的代码可能会中断。您将不再获得名字和姓氏。 你必须明白WADL是一个协议。如果必须更改，则需要通知客户端。为了避免破坏客户端代码，我们发布了新版本的API。 版本1.0将具有名字和姓氏，而不会破坏您的代码。我们将发布1.1版本，将更改为全名。 简而言之，WADL就是留下来的。只要您使用该版本的API。你的代码不会破坏。如果要获取全名，则必须转到新版本。由于技术市场中有许多代码生成插件，生成代码应该不是问题。 回答你的下一个问题，为什么不WADL以及你如何了解mime类型。 WADL用于代码生成并用作合同。有了它，您可以使用JAXB或任何映射框架将JSON字符串转换为生成的bean对象。 如果不是WADL，则不需要检查每个元素以确定类型。你可以轻松地做到这一点。   var obj =   jQuery.parseJSON（ '{ “名”： “约翰”}'）;   alert（obj.name ===“John”）; 让我知道，如果您有任何疑问。