rest - 使用 REST 代替非 REST HTTP 的优点是什么？

Question

显然，REST is just a set of conventions about how to use HTTP 。我想知道这些约定提供了哪些优势。有人知道吗？

Answer 1

我认为您不会对此得到一个好的答案，部分原因是没有人真正同意 REST 是什么。。 wikipedia page流行语较多，解释较少。讨论页面值得浏览一下，看看有多少人对此持不同意见。然而，据我所知，REST 意味着:

我们尝试让 URL 识别资源，而不是随机命名 setter 和 getter URL 并对所有 getter 使用 GET 并为所有 setter 使用 POST然后使用 HTTP 操作 GET、POST、PUT 和 DELETE 对它们执行操作。所以而不是

GET /get_article?id=1
POST /delete_article   id=1

你会做

GET /articles/1/
DELETE /articles/1/

然后 POST 和 PUT 对应于“创建”和“更新”操作(但没有人同意哪种方式)。

我认为缓存参数是错误的，因为查询字符串通常会被缓存，而且您实际上并不需要使用它们。例如，django 使这样的事情变得非常简单，我不会说它是 REST:

GET /get_article/1/
POST /delete_article/     id=1

或者甚至只是在 URL 中包含动词:

GET /read/article/1/
POST /delete/article/1/
POST /update/article/1/
POST /create/article/

在这种情况下，GET 意味着没有副作用，而 POST 意味着更改服务器上的数据。我认为这可能更清晰、更容易，特别是因为您可以避免整个 PUT-vs-POST 事情。另外，如果您愿意，您可以添加更多动词，这样您就不会人为地受限于 HTTP 提供的内容。例如:

POST /hide/article/1/
POST /show/article/1/

(或者无论如何，在事情发生之前很难想到例子!)

总而言之，我认为只有两个优点:

1. 您的 Web API 可能会更简洁、更容易理解/发现。
2. 与网站同步数据时，使用 REST 可能更容易，因为您可以直接输入 synchronize("/articles/1/") 或其他内容。这在很大程度上取决于您的代码。

但是我认为有一些相当大的缺点:

1. 并非所有操作都能轻松映射到 CRUD(创建、读取/检索、更新、删除)。您甚至可能没有处理对象类型资源。
2. 为了可疑的好处而付出的额外努力。
3. 对于 PUT 和 POST 的方式存在混淆。在英语中，它们的意思相似(“我要在墙上贴/张贴通知。”)。

因此，我想说的是:除非您真的想付出额外的努力，或者您的服务非常适合 CRUD 操作，否则请为 API 的第二个版本保留 REST。

<小时/>

我刚刚遇到了 REST 的另一个问题:在一个请求中执行多项操作或指定要获取复合对象的哪些部分并不容易。这对于移动设备尤其重要，因为移动设备的往返时间可能很长并且连接不可靠。例如，假设您正在 Facebook 时间线上获取帖子。 “纯粹的”REST 方式类似于

GET /timeline_posts     // Returns a list of post IDs.
GET /timeline_posts/1/  // Returns a list of message IDs in the post.
GET /timeline_posts/2/
GET /timeline_posts/3/
GET /message/10/
GET /message/11/
....

这有点可笑。在我看来，Facebook 的 API 非常棒，所以让我们看看他们做了什么:

By default, most object properties are returned when you make a query. You can choose the fields (or connections) you want returned with the "fields" query parameter. For example, this URL will only return the id, name, and picture of Ben: https://graph.facebook.com/bgolub?fields=id,name,picture

我不知道你会如何使用 REST 来做类似的事情，如果你这样做了它是否仍然算作 REST。我当然会忽略任何试图告诉您不应该这样做的人(特别是如果原因是“因为它不是 REST”)!