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

Question

我一直在努力理解我一直在阅读有关RESTful服务的几点.我希望有人可以帮忙澄清一下.

1a)在讨论RESTful服务时似乎普遍厌恶生成的代码.

1b)如果您使用WADL为RESTful服务生成客户端,则在服务更改时 - 您的客户端代码也是如此.

为什么我没有得到它:无论您是引用WADL还是使用生成的代码,或者您是否已从RESTful响应中手动提取数据并将其映射到您的UI(或者您正在使用它们执行的任何操作),如果底层更改了某些内容服务似乎在两种情况下代码都会崩溃.例如,如果返回的数据从FirstName和LastName更改为FullName,则在两个实例中都必须更新代码以获取新字段,并且可能以不同方式处理它.

2)RESTful服务不需要WADL的论点,因为返回类型应该是众所周知的MIME类型,并且您应该已经知道如何处理它们.

为什么我没有得到它:是否期望对于服务返回的每个"类型"数据,将存在唯一的MIME类型？如果是这种情况,那是否意味着RESTful服务的使用者应该阅读RFC以确定返回数据的结构,如何使用每个字段等？

我已经做了很多阅读,试图为自己解决这个问题,所以我希望有人可以提供具体的例子和现实世界的场景.

Answer 1

休息可以是非常微妙的。我还读了很多关于它的书，每隔一段时间我就会回去阅读菲尔丁论文的第五章，每次都能找到更多的见解。第一次它像泥一样清晰（尽管有些事情是有道理的），但只有当我尝试应用这些原则并使用构建块时，它才变得更好。

\n\n

因此，根据我目前的理解，让我们尝试一下：

\n\n

为什么 RESTafarians 不喜欢代码生成？

\n\n

简短的回答：如果您使用超媒体（+链接），则不需要。

\n\n

上下文：在客户端和服务器之间显式定义契约 (WADL) 并不足以减少耦合：如果更改服务器，客户端就会中断，并且需要重新生成代码。（恕我直言，甚至自动化它也只是解决潜在耦合问题的补丁）。

\n\n

REST 可帮助您在不同级别上解耦。超媒体的可发现性是值得入手的优点之一。另请参见相关概念HATEOAS

\n\n

我们让客户端 \xe2\x80\x9cdiscover\xe2\x80\x9d 从我们正在操作的资源中可以做什么，而不是之前定义合约。我们加载资源，检查 \xe2\x80\x9cnamed links\xe2\x80\x9d，然后按照这些链接或填写表单（或表单链接）来更新资源。服务器通过基于状态建议的选项充当客户端的指南。（想想业务流程/工作流程/行为）。如果我们使用合约，我们需要知道这个“带外”信息并在变更时更新合约。

\n\n

如果我们使用带有链接的超媒体，则不需要 \xe2\x80\x9c 单独的合约\xe2\x80\x9d。一切都包含在超媒体\xe2\x80\x93中为什么要设计一个单独的文件？即使 URI 模板也是带外信息，但如果保持简单，也可以像 Amazon S3 一样工作。

\n\n

是的，我们在传输表示形式（超媒体）时仍然需要一个共同点，因此我们定义您自己的媒体类型或使用广泛接受的媒体类型，例如 Atom 或Micro-format。因此，在基本构建块（链接+表单+数据-超媒体）的约束下，我们通过将带外信息保持在最低限度来减少耦合。

\n\n

首先，采用超媒体似乎并没有改变变化的影响:)：但是，存在细微的差异。首先，如果我有 WADL，我需要更新另一个文档并部署/分发。使用纯超媒体不会产生任何影响，因为它是嵌入式的。（想象一下通过复杂的系统交织而产生的变化）。根据您的示例，具有 FirstName + LastName 并添加 FullName 并不会真正影响客户端，但删除 First+Last 并替换为 FullName 即使在超媒体中也会产生影响。

\n\n

附带说明：REST 统一接口（动词约束 - GET、PUT、POST、DELETE + 其他动词）将实现与服务解耦。

\n\n

也许我完全错了，但另一种可能性可能是 \xe2\x80\x9c 对代码生成的心理反冲\xe2\x80\x9d：WADL 让人想到 \xe2\x80\x9c 传统网络中的 WSDL（合约）部分services (WSDL+SOAP)\xe2\x80\x9d / RPC 违背了 REST。在 REST 中，状态是通过超媒体而不是 RPC 传输的，RPC 是更新服务器上状态的方法调用。

\n\n

免责声明：我还没有详细完成参考文章，但我确实给出了一些重要的观点。

\n