web-services - 您能否帮助澄清有关 RESTful 服务和代码生成的一些要点？

Question

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

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

1b) 如果您使用 WADL 为 RESTful 服务生成客户端，那么当服务更改时，您的客户端代码也会更改。

为什么我不明白:无论您是在引用 WADL 并使用生成的代码，还是您已经从 RESTful 响应中手动提取数据并将它们映射到您的 UI(或您正在使用它们做的任何事情)，如果底层发生了变化服务似乎在这两种情况下代码都会中断。例如，如果返回的数据从 FirstName 和 LastName 更改为 FullName，那么在这两种情况下，您都必须更新代码以获取新字段并可能以不同方式处理它。

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

为什么我不明白:是否期望服务返回的每种“类型”数据都会存在唯一的 MIME 类型？如果是这种情况，是否意味着 RESTful 服务的消费者需要阅读 RFC 以确定返回数据的结构、如何使用每个字段等？

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

Answer 1

REST 可能非常微妙。我也读了很多书，每隔一段时间我就会回去阅读Chapter 5 of Fielding's dissertation。 ，每次都能找到更多的洞察力。第一次时它像泥巴一样清晰(尽管有些事情是有道理的)，但只有在我尝试应用这些原则并使用构建 block 时才变得更好。

所以，根据我目前的理解，让我们试一试:

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

简短的回答:如果您使用超媒体(+链接)则没有必要。

上下文:显式定义客户端和服务器之间的契约(Contract) (WADL) 不会减少耦合 够了 :如果您更改服务器，客户端会中断，您需要重新生成代码。 (恕我直言，甚至自动化它只是潜在耦合问题的一个补丁)。

REST 帮助您在不同级别上解耦。 超媒体可发现性 是开始的商品之一。另见相关概念HATEOAS

我们让客户“发现”可以从我们的资源中做些什么 经营 on 而不是之前定义的契约(Contract)。我们加载资源，检查“命名链接”，然后点击这些链接或填写表格(或表格链接)以更新资源。服务器通过它根据状态提出的选项充当客户端的指南。 (想想业务流程/工作流/行为)。如果我们使用契约(Contract)，我们需要知道这个“带外”信息并在更改时更新契约(Contract)。

如果我们使用带有链接的超媒体，则不需要“单独的契约(Contract)”。一切都包含在超媒体中——为什么要设计一个单独的文档？甚至 URI 模板也是带外信息，但如果保持简单，则可以像 Amazon S3 一样工作。

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

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

附带说明:REST 统一接口(interface)(动词约束 - GET、PUT、POST、DELETE + 其他动词)将实现与服务分离。

也许我完全错了，但另一种可能性可能是对代码生成的“心理反击”:WADL 让人想到“传统 Web 服务 (WSDL+SOAP)”/RPC 中的 WSDL(契约(Contract))部分，它与 REST 相悖。在 REST 中，状态是通过超媒体而不是 RPC 传输的，RPC 是用于更新服务器状态的方法调用。

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