Questions tagged «http-method»

首先，一些定义： PUT在9.6节RFC 2616中定义： PUT方法请求将封闭的实体存储在提供的Request-URI下。如果Request-URI引用了已经存在的资源，则应将封闭的实体视为原始服务器上的资源的修改版本。如果Request-URI没有指向现有资源，并且请求用户代理能够将该URI定义为新资源，则原始服务器可以使用该URI创建资源。 PATCH在RFC 5789中定义： PATCH方法请求将在请求实体中描述的一组更改应用于由Request-URI标识的资源。 同样根据RFC 2616第9.1.2节， PUT是幂等的，而PATCH不是。 现在让我们看一个真实的例子。当我/users对数据执行POST {username: 'skwee357', email: 'skwee357@domain.com'}并服务器能够创建资源时，它将以201和资源位置（假设/users/1）响应，并且对GET的下一次调用/users/1将返回{id: 1, username: 'skwee357', email: 'skwee357@domain.com'}。 现在，让我们说我想修改我的电子邮件。电子邮件修改被视为“一组更改”，因此我应该/users/1使用“ 补丁文档 ”来进行修补。在我的情况下，它将是json文档：{email: 'skwee357@newdomain.com'}。然后，服务器返回200（假设允许）。这使我想到第一个问题： 补丁不是幂等的。它在RFC 2616和RFC 5789中是这样说的。但是，如果我发出相同的PATCH请求（使用我的新电子邮件），我将获得相同的资源状态（将我的电子邮件修改为请求的值）。为什么PATCH不那么幂等？ PATCH是一个相对较新的动词（2010年3月引入RFC），用于解决“修补”或修改一组字段的问题。在引入PATCH之前，每个人都使用PUT来更新资源。但是在引入PATCH之后，我对PUT的用途感到困惑。这使我想到了第二个（也是主要的）问题： PUT和PATCH之间的真正区别是什么？我在某处读到了PUT可能用于替换特定资源下的整个实体，因此应该发送完整的实体（而不是像PATCH那样发送一组属性）。这种情况的实际实际用途是什么？您何时要替换/覆盖特定资源URI上的实体，为什么不考虑将此类操作更新/修补该实体？我在PUT上看到的唯一实际用例是在集合上发布PUT，即/users替换整个集合。引入PATCH之后，在特定实体上发布PUT毫无意义。我错了吗？

680 json  rest  http  put  http-method 

我想使用适合以下情况的方法设计其余端点。 有一个小组。每个组都有一个状态。该组可以由管理员激活或停用。 我应该将终点设计为 PUT /groups/api/v1/groups/{group id}/status/activate 要么 PATCH /groups/api/v1/groups/{group id} with request body like {action:activate|deactivate}

274 http  rest  http-put  http-method  http-patch 

使用GET或POST方法有什么区别？哪一个更安全？它们各自的（缺点）优点是什么？ （类似的问题）

249 forms  http  post  get  http-method 

在RESTful样式编程中，我们应该使用HTTP方法作为构建基块。尽管有些方法与经典的CRUD方法匹配，但我有些困惑。GET / Read和DELETE / Delete很明显。 但是，PUT / POST有什么区别？它们是否与创建和更新一对一匹配？

213 http  rest  crud  http-method 

Curl提供了一系列不同的带有X前缀的http方法调用，但也提供了没有的相同方法。我已经尝试过两者，但似乎无法找出区别。有人可以快速向我解释这两种操作有何不同吗？

126 curl  http-method 

尽管HTTP 1.1规范似乎允许DELETE请求上的消息正文，但它似乎表明服务器应该忽略它，因为没有定义的语义。 4.3邮件正文 服务器应根据任何请求读取并转发消息正文；如果请求方法不包括为实体主体定义的语义，则在处理请求时应忽略消息主体。 我已经回顾了关于SO及其它主题的一些相关讨论，例如： 是否允许实体正文进行HTTP DELETE请求？ HTTP请求方法的有效载荷 带请求正文的HTTP GET 大多数讨论似乎都同意，可以允许在DELETE上提供消息正文，但通常不建议这样做。 此外，我注意到各种HTTP客户端库中都有一种趋势，其中越来越多的增强功能正在被记录下来以支持DELETE上的请求主体。尽管偶尔会有一些最初的阻力，但大多数图书馆似乎都有义务。 我的用例要求在DELETE上添加一些必需的元数据（例如，删除的“原因”，以及删除所需的其他一些元数据）。我考虑过以下选项，这些选项似乎都不是完全合适的，并且符合HTTP规范和/或REST最佳实践： 邮件正文 -规范表明DELETE上的邮件正文没有语义值；HTTP客户端未完全支持；不是标准做法 自定义HTTP标头 -要求自定义标头通常违反标准做法；使用它们与我的其余API不一致，所有这些都不需要自定义标头；此外，没有良好的HTTP响应可用来指示不良的自定义标头值（可能是一个单独的问题） 标准HTTP标头-没有合适的标准标头 查询参数 -添加查询参数实际上会更改要删除的Request-URI；违反标准做法 POST方法 -（例如POST /resourceToDelete { deletemetadata }）POST不是删除的语义选项；POST实际上表示所需的相反操作（即POST创建资源下属；但是我需要删除资源） 多种方法 -将DELETE请求拆分为两个操作（例如，先删除PUT删除元数据，然后执行DELETE），将一个原子操作拆分为两个，可能会导致状态不一致。删除原因（以及其他相关的元数据）不是资源表示本身的一部分。 我的第一个偏好可能是使用消息正文，其次是自定义HTTP标头。但是，如所示，这些方法存在一些缺点。 是否有符合REST / HTTP标准的任何建议或最佳做法，以将此类必需的元数据包括在DELETE请求中？还有其他我没有考虑过的选择吗？

93 http  rest  httprequest  http-method 

我想知道在执行登录请求时应该使用哪种http方法，为什么？由于此请求在服务器上创建了一个对象（用户会话），因此我认为应该是POST，您如何看待？但是由于登录请求应该是幂等的，所以可以是PUT，不是吗？ 有关注销请求的相同问题，我应该使用DELETE方法吗？

93 login  logout  http-method 

HTTP上的Wikipedia条目列出了以下HTTP请求方法： HEAD：请求与GET请求相同的响应，但没有响应主体。 GET：请求表示指定资源。 POST：将要处理的数据（例如，从HTML表单）提交到标识的资源。数据包含在请求的正文中。 PUT：上载指定资源的表示。 DELETE：删除指定的资源。 跟踪：回显收到的请求，以便客户端可以看到中间服务器所做的更改（如有）或添加的内容。 选项：返回服务器支持的指定URL的HTTP方法。可以通过请求“ *”而不是特定资源来检查Web服务器的功能。 CONNECT：将请求连接转换为透明的TCP / IP隧道，通常是为了通过未加密的HTTP代理促进SSL加密的通信（HTTPS）。 补丁：用于对资源进行部分修改。 我有兴趣了解（特别是关于前五个方法）： 这些方法中的哪一个能够（应该？）接收有效载荷 可以接收有效载荷的方法中，它们如何接收？ 通过URL中的查询字符串？ 通过URL编码的正文？ 通过原始/分割的身体？ 通过以上（[全部/部分]的组合）？ 感谢您的所有投入，如果您可以分享一些（最好是轻度的）阅读，那太好了！

68 http  rest  request  http-method  payload