1

我应该为应用程序制作 Web 服务，并认为我可以很好地实践良好的实践。我发现它使用的是 REST。但有一件事在其中毫无意义。

为什么使用 URI 来传递任何变量？

我们在上一个项目中所做的是仅使用 POST 并将任何内容作为原始 POST 数据（即 JSON）传递。这不是很 RESTful。但它有一些优点。这在客户端非常简单——我有一个通用函数，它将 URI 和数据作为参数，然后将其包装并发送。

现在，如果我使用正确的 REST，我将不得不将一些数据作为 URI 的一部分（例如，用户 ID）传递。我猜所有其他数据（用户名、电子邮件等）都必须像我们一样作为原始数据。这意味着我必须在某个时候将用户 ID 和其他数据分开。这还不错，但仍然 - 为什么？

编辑 这是一个更详细的例子：

假设您要访问 (GET) 和更新 (POST) 用户数据。您可能在/user下可以访问一个服务，但 RESTful 服务会接受用户 ID 作为 URI ( /user/1234 ) 的一部分。所有其他数据（姓名、电子邮件等）都将用于请求内容（可能是 JSON）。

我提出的是，将用户 ID 放在 URI 中似乎没用。如果您想更新用户数据 - 无论如何您都会将附加数据作为内容发送。如果您想访问它 - 您可以使用相同的通用方法来请求 Web 服务。

我知道 GET 会被浏览器缓存，但我相信如果您使用 AJAX（网络）或任何 HTTP 客户端库（其他平台），无论如何您都必须手动缓存它。

从可扩展性的角度来看 - 您始终可以添加更多服务。

4

2 回答 2

3

您使用 URI 来识别要使用的资源（用户/文档/网页），并在请求中传递相关数据。

它的优点是 Web 基础架构组件可以在不知道您的内容是如何表示的情况下找出资源的位置。例如，您可以使用标准缓存和负载均衡器，它们只需要知道 URL 和标头（它们总是以相同的方式表示）是否使用 JSON、protobuf 或 WAV 音频与您的资源进行通信是无关紧要的。

例如，这将让您将不同的资源保存在完全不同的位置，如果您将其全部作为内容发送，您将无法将资源放置在完全不同的位置，例如http://cloud.google .com/resource1和http://cloud.amazon.com/resource2。

所有这些都将允许您进行大规模扩展，如果您将其全部放在http://my.url.com/rest上并将所有资源信息作为内容传递，您将无法做到这一点。

回复：您的编辑

在 URL 中传递用户 ID是识别单个资源（用户）的唯一方法。请记住，资源是用户，而不是“用户存储”。

例如，缓存http://my.url/user的缓存不会很好，因为它会为每个用户返回相同的缓存页面。如果缓存可以与http://my.url/user/4711 一起使用，它可以单独缓存每个用户。同样，负载均衡器可以知道用户 1-5000 由一台机器处理，5001-10000 由另一台机器处理，等等，并仅根据 URL 做出智能决策。

于 2012-08-26T06:07:04.063 回答
0

将 RESTful Web 服务想象为数据库。要获取或修改特定对象，您需要通过提供其主键来识别它。您通过他的 ID 来识别用户，而不是他的姓名+昵称+电子邮件+母亲的娘家姓。标识一个对象或选择一组对象的信息转到 URL。修改对象的信息应该发布到相应的 URL。

于 2013-01-25T00:42:58.037 回答