Question

我想了解REST架构，但我有一个问题。

我不明白@POST和@GET之间的所有差异...对我来说，我只是从技术的角度来看它们，我的框架（GWT-P）允许我使用各种参数（String使用@POST和各种参数（包括ONLY ONE对象类）和@POST ...

那么，如果我使用的是@POST而不是@GET，我可以创建什么样的错误（逻辑错误，糟糕的架构等...）？因为，例如，如果我想要检索数据，使用@GET似乎合乎逻辑，不是吗？但是，如果我想传递大量有用的参数来检索这些数据（例如：日期，地点，用户......），那么技术上，我必须使用@POST ..

那么，@ GET，@ POST？是否必须尊重所有“检索操作”（我的意思是获取数据操作）应该是@GET而不是@POST的逻辑？

Thansk你，

Answer 1

首先，REST是一种架构风格，因此它与协议无关。您的问题与正确使用HTTP而不是REST有关。

如果需要在检索中传递参数，则应将它们发送到查询字符串中，而不是POST中。请记住，整个URI（包括查询字符串）是资源的原子标识符。

使用POST检索的问题是此方法是为非幂等操作保留的，这可能会对服务器端产生一些副作用。例如，POST永远不会被缓存，如果响应丢失而没有先检查请求是否实际成功，则客户端无法随意重新提交POST。

Answer 2

在REST逻辑中：

GET =＆gt;获取资源（带有id）
POST =＆gt;创建资源
PUT =＆gt;更新资源（带有id）
DELETE =＆gt;删除资源（带有id）

很少需要为资源指定许多参数（否则，就会出现问题在软件设计中）。

通常只有标识符作为参数（或标识符和资源类型，libel，......，但不超过HTTP / GET中参数的限制数量）。

Answer 3

基本上这些HTTP方法只是语义，它们的用途只是一个指导原则。

然而，当处理服务器端的这些请求时，请记住，Web爬虫也使用这些方法，因此，例如，除了显示数据之外，使GET请求做任何事情都是不安全的，并且可能会产生一些难以跟踪的问题。应用

对此更多一点。 http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Safe_methods

Answer 4

如果您为此发布API，那么我将使用@GET方法，但如果不是这种情况，请务必使用@POST。

@POST为您提供了更多选项，并且对参数查询字符串长度没有限制，如@GET，唯一的负面因素是@POST创建请求的速度慢了几毫秒。

Answer 5

如果您需要将查询信息传递给URI以准确指定您想要的资源，请不要使用POST。将GET与查询字符串一起使用。

例如

http://myapi.com/someresource?day=01012014&place=Dublin&user=JohnDoe

或者如果有一个有意义的层次结构，那么将其构建到URI本身

http://myapi.com/users/JohnDoe/locations/Dublin/telephones/01231414

在REST架构中区分@GET @POST

5 个答案: