休息服务约定 [英] Rest Services conventions
问题描述
在 Rest 服务中，当我们想要从服务器检索一些数据时，我们通常使用 'GET' 请求，但是我们也可以使用 'POST' 请求检索数据.我们使用POST"来创建，PUT"来更新，DELETE"来删除，但是我们甚至可以使用DELETE"请求来创建新数据.
In Rest Services,we normally use 'GET' requests when we want to retrieve some data from the server, however we can also retrieve data using a 'POST' request. We use 'POST' to create, 'PUT' to update, and 'DELETE' to delete, however we can even create new data using a 'DELETE' request.
所以我只是想知道背后的真正原因是什么，为什么要使用这些约定?
So I was just wondering what is the real reason behind for that, why these conventions are used?
推荐答案
所以我只是想知道背后的真正原因是什么，为什么要使用这些约定?
So I was just wondering what is the real reason behind for that, why these conventions are used?
所以世界不会分崩离析！
So the world doesn't fall apart!
不，但说真的，为什么要创建任何协议或标准?以这个历史场景为例.在 Google 的早期，许多开发人员(相对于现在)对 HTTP 协议还不太了解.您可能已经发现了一堆刚刚使用众所周知的(也许仅已知的)GET 方法的站点.所以会有一些链接是 GET 请求，但会执行本应是 POST 请求的操作，这会改变服务器的状态(有时是非常重要的状态变化).进入谷歌，它每天都在抓取网络.所以现在你有了谷歌正在抓取的所有这些链接，所有这些都是 GET 请求的链接，但是改变了服务器的状态.所以所有这些公司都在改变状态的服务器上获得了大量点击.他们都认为自己受到了攻击！但谷歌并没有做错任何事.HTTP 语义声明 GET 请求不应具有状态更改行为.它应该是一种只读"方法.所以最终这些公司变聪明了，开始遵循 HTTP 语义.真实故事.
No but seriously, why are any protocols or standards created? Take this historical scenario. Back in the early days of Google, many developers (relative to nowadays) weren't too savvy on the HTTP protocol. What you might've caught was a bunch of sites who just made use of the well known (maybe only known) GET method. So there would be links that would be GET requests, but would perform operations that were meant to be POST request, that would change the state of the server (sometimes very important changes of state). Enter Google, who spends its days crawling the web. So now you have all these links that Google is crawling, all these links that are GET requests, but changing the state of the server. So all these companies are getting a bunch of hits on their servers changing state. They all think they're being attacked! But Google isn't doing anything wrong. HTTP semantics state that GET requests should not have state changing behaviors. It should be a "read only" method. So finally these companies smartened up, and started following HTTP semantics. True story.
这个故事的寓意:遵循协议，这就是他们的目的 - 遵循.
The moral of the story: follow protocols, that's what they're there for - to follow.
您似乎是从服务器实现的角度来看的.是的，您可以实现您的服务器以接受 DELETE 请求以获取"某些东西.这不是真正的问题.在实现服务器时，您需要考虑客户端的期望.我的意思是最终，您正在创建一个 API.从代码API的角度来看
You seem to be looking at it from the perspective of server implementation. Yeah you can implement your server to accept DELETE request to "get" something. That's not really the matter at hand. When implementing the server, you need to think about what the client expects. I mean ultimately, you are creating an API. Look at it from a code API perspective
public class Foo {
public Bar bar;
public Bar deleteBar() {
return bar; // Really?!
}
public void getBar() {
bar = null; // What the..??!
}
}
我不知道一个开发者能在游戏中坚持多久，写出这样的代码.任何希望获取"Bar(仅通过命名语义)的调用者都有另一件事要做.您的 REST 服务也是如此.它归根结底是一个 WEB API，应该遵循它所建立的协议(即 HTTP)的语义.那些了解协议的人，会根据他们提出的请求类型，了解 API 的作用(至少在 CRUD 意义上).
I don't know how long a developer would last in the game, writing code like that. Any callers expecting to "get" Bar (simply by naming semantics) has another thing coming. Same goes for your REST services. It is ultimately a WEB API, and should follow the semantics of the protocol (namely HTTP) on which it is built. Those who understand the protocol, will have an idea of what the API does (at least in the CRUD sense), simply based on the type of request they make.
我对您或任何试图学习 REST 的人的建议是，好好掌握 HTTP.我会随身携带以下文件.读一遍，留作参考
My suggestion to you or anyone trying to learn REST, is to get a good handle on HTTP. I would keep the following document handy. Read it once, then keep it as a reference
这篇关于休息服务约定的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
