而不是非

而不是非

关注
发信
关注(28)粉丝(399)

使用 REST 而不是非 REST HTTP 的优势是什么?

本文介绍了使用 REST 而不是非 REST HTTP 的优势是什么?的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

显然，REST 只是一套关于如何使用的约定HTTP.我想知道这些约定提供了哪些优势.有人知道吗?

Apparently, REST is just a set of conventions about how to use HTTP. I wonder which advantage these conventions provide. Does anyone know?

推荐答案

我不认为你会得到一个好的答案，部分原因是没有人真正同意 REST 是什么.维基百科页面大量使用流行语，而很少进行解释.讨论页面值得浏览一下，看看有多少人对此持不同意见.然而，据我所知，REST 的意思是:

I don't think you will get a good answer to this, partly because nobody really agrees on what REST is. The wikipedia page is heavy on buzzwords and light on explanation. The discussion page is worth a skim just to see how much people disagree on this. As far as I can tell however, REST means this:

我们不是使用随机命名的 setter 和 getter URL 并为所有 getter 使用 GET 并为所有 setter 使用 POST，而是尝试让 URL 标识资源，并且然后使用 HTTP 操作 GET、POST、PUT 和 DELETE 对它们进行处理.所以代替

Instead of having randomly named setter and getter URLs and using GET for all the getters and POST for all the setters, we try to have the URLs identify resources, and then use the HTTP actions GET, POST, PUT and DELETE to do stuff to them. So instead of

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

你会的

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

然后 POST 和 PUT 分别对应创建"和更新"操作(但没有人同意哪个方向).

And then POST and PUT correspond to "create" and "update" operations (but nobody agrees which way round).

我认为缓存参数是错误的，因为查询字符串通常被缓存，此外你并不真正需要使用它们.例如 django 使这样的事情变得非常简单，我不会说它是 REST:

I think the caching arguments are wrong, because query strings are generally cached, and besides you don't really need to use them. For example django makes something like this very easy, and I wouldn't say it was REST:

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

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

Or even just include the verb in the URL:

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

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

In that case GET means something without side-effects, and POST means something that changes data on the server. I think this is perhaps a bit clearer and easier, especially as you can avoid the whole PUT-vs-POST thing. Plus you can add more verbs if you want to, so you aren't artificially bound to what HTTP offers. For example:

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

(或者其他什么，在它们发生之前很难想到例子！)

(Or whatever, it's hard to think of examples until they happen!)

总之，我能看到的优点只有两个:

So in conclusion, there are only two advantages I can see:

  1. 您的 Web API 可能更简洁、更易于理解/发现.
  2. 在与网站同步数据时，使用 REST 可能更容易，因为您可以直接说 synchronize("/articles/1/") 或其他什么.这在很大程度上取决于您的代码.
  1. Your web API may be cleaner and easier to understand / discover.
  2. When synchronising data with a website, it is probably easier to use REST because you can just say synchronize("/articles/1/") or whatever. This depends heavily on your code.

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

However I think there are some pretty big disadvantages:

  1. 并非所有操作都能轻松映射到 CRUD(创建、读取/检索、更新、删除).您甚至可能不会处理对象类型资源.
  2. 为可疑的利益付出额外的努力.
  3. 混淆 PUT 和 POST 的方向.在英语中，它们的意思相似(我要在墙上贴/张贴通知.").
  1. Not all actions easily map to CRUD (create, read/retrieve, update, delete). You may not even be dealing with object type resources.
  2. It's extra effort for dubious benefits.
  3. Confusion as to which way round PUT and POST are. In English they mean similar things ("I'm going to put/post a notice on the wall.").

总之，我想说:除非你真的想付出额外的努力，或者如果你的服务很好地映射到 CRUD 操作，请为你的 API 的第二个版本保存 REST.

So in conclusion I would say: unless you really want to go to the extra effort, or if your service maps really well to CRUD operations, save REST for the second version of your API.

我刚刚遇到了 REST 的另一个问题:在一个请求中做多件事或指定要获取复合对象的哪些部分并不容易.这在往返时间可能很长且连接不可靠的移动设备上尤其重要.例如，假设您在 facebook 时间轴上收到帖子.纯" REST 方式类似于

I just came across another problem with REST: It's not easy to do more than one thing in one request or specify which parts of a compound object you want to get. This is especially important on mobile where round-trip-time can be significant and connections are unreliable. For example, suppose you are getting posts on a facebook timeline. The "pure" REST way would be something like 

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 非常适合 IMO，让我们看看他们做了什么:

Which is kind of ridiculous. Facebook's API is pretty great IMO, so let's see what they do:

默认情况下，大多数对象属性会在您进行查询时返回.您可以选择要返回的字段(或连接)字段"查询参数.例如，此 URL 将仅返回Ben 的 ID、姓名和照片:https://graph.facebook.com/bgolub?fields=id,name,picture

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

I have no idea how you'd do something like that with REST, and if you did whether it would still count as REST. I would certainly ignore anyone who tries to tell you that you shouldn't do that though (especially if the reason is "because it isn't REST")!

这篇关于使用 REST 而不是非 REST HTTP 的优势是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！

09-05 21:50
Powered by LMLPHP ©2024 而不是非 0.051961