几天后我才注意到这个问题，但我觉得我可以补充一些见解。我希望这能对你的平安创业有所帮助。

---

第一点:我理解得对吗?

你理解得对。这是RESTful体系结构的正确表示。你可能会发现维基百科上的以下矩阵对定义名词和动词很有帮助:

---

当处理类似于http://example.com/resources/的集合URI时

GET:列出集合的成员，包括它们的成员uri，以便进一步导航。例如，列出所有待售的汽车。 PUT:意思是“用另一个集合替换整个集合”。 POST:在集合中创建一个新条目，其中ID由集合自动分配。创建的ID通常包含在此操作返回的数据中。 DELETE:定义为“删除整个集合”。

---

当处理像http://example.com/resources/7HOU57Y这样的成员URI时

GET:检索以适当MIME类型表示的已寻址集合成员的表示形式。 PUT:更新集合的已寻址成员或使用指定的ID创建它。 POST:将已寻址的成员作为其本身的集合处理，并创建它的新从属。 DELETE:删除集合的寻址成员。

---

第二点:我需要更多的动词

一般来说，当您认为需要更多动词时，实际上可能意味着需要重新标识资源。记住，在REST中，您总是作用于一个资源或资源的集合。选择什么作为资源对API定义非常重要。

激活/取消激活登录:如果您正在创建一个新会话，那么您可能希望将“会话”视为资源。要创建一个新会话，使用POST到http://example.com/sessions/，并在主体中使用凭据。要使其过期，请使用PUT或DELETE(可能取决于您是否打算保留会话历史)到http://example.com/sessions/SESSION_ID。

Change Password:这次的资源是“the user”。您需要一个到http://example.com/users/USER_ID的PUT，并将旧密码和新密码放在主体中。您正在对“用户”资源进行操作，更改密码只是一个更新请求。它与关系数据库中的UPDATE语句非常相似。

我的直觉是执行GET调用 到一个URL / api /用户/ 1 / activate_login

这违背了REST的核心原则:正确使用HTTP动词。任何GET请求都不应该留下任何副作用。

例如，GET请求永远不应该在数据库上创建会话，返回带有新会话ID的cookie，或者在服务器上留下任何残留物。GET动词类似于数据库引擎中的SELECT语句。请记住，当使用相同的参数请求时，对带有GET谓词的任何请求的响应都应该是可缓存的，就像请求静态web页面一样。

---

要点3:如何返回错误消息和代码

将4xx或5xx HTTP状态代码视为错误类别。您可以在正文中详细说明错误。

连接数据库失败:/数据库登录不正确:一般情况下，您应该使用500错误来处理这些类型的错误。这是一个服务器端错误。客户没有做错什么。500个错误通常被认为是“可重试的”。也就是说，客户端可以重试相同的请求，并期望它在服务器的问题解决后成功。在正文中指定细节，以便客户端能够为我们人类提供一些上下文。

另一类错误是4xx族，它通常表示客户端做错了什么。特别是，这类错误通常向客户端表明，不需要按原样重试请求，因为它将继续永久地失败。也就是说，客户端在重新尝试这个请求之前需要修改一些东西。例如，“资源未找到”(HTTP 404)或“格式错误请求”(HTTP 400)错误就属于这一类。

---

要点4:如何进行身份验证

正如第1点所指出的，您可能希望考虑创建一个会话，而不是验证用户。您将返回一个新的“会话ID”，以及相应的HTTP状态代码(200:允许访问或403:拒绝访问)。

然后，您将询问RESTful服务器:“您可以为我获取这个会话ID的资源吗?”

没有身份验证模式——REST是无状态的:你创建一个会话，你要求服务器使用这个会话ID作为参数给你资源，在注销时你删除或过期会话。

使用post当你不知道如何新的资源URI看起来像(你创建新用户，应用程序将分配新用户它的id)， PUT更新或创建资源，你知道他们将如何表示(示例:PUT /myfiles/thisismynewfile.txt) 在消息正文中返回错误描述 您可以使用HTTP身份验证(如果足够的话) Web服务应该是状态

详细，但复制自http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html上的HTTP 1.1方法规范

9.3获得

GET方法意味着检索由Request-URI标识的任何信息(以实体的形式)。如果Request-URI指的是一个产生数据的流程，则应将产生的数据作为响应中的实体返回，而不是流程的源文本，除非该文本恰好是流程的输出。

The semantics of the GET method change to a "conditional GET" if the request message includes an If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, or If-Range header field. A conditional GET method requests that the entity be transferred only under the circumstances described by the conditional header field(s). The conditional GET method is intended to reduce unnecessary network usage by allowing cached entities to be refreshed without requiring multiple requests or transferring data already held by the client.

如果请求消息包含一个Range报头字段，GET方法的语义将更改为“部分GET”。部分GET请求只传输实体的一部分，如第14.35节所述。partial GET方法旨在通过允许完成部分检索的实体而不传输已经由客户端持有的数据来减少不必要的网络使用。

当且仅当GET请求的响应满足第13节中描述的HTTP缓存要求时，该响应是可缓存的。

关于表单使用时的安全注意事项，请参见15.1.3节。

9.5发布

POST方法用于请求源服务器接受请求中包含的实体，作为request - line中由request - uri标识的资源的新附属。POST被设计为允许一个统一的方法覆盖以下函数:

  - Annotation of existing resources;
  - Posting a message to a bulletin board, newsgroup, mailing list,
    or similar group of articles;
  - Providing a block of data, such as the result of submitting a
    form, to a data-handling process;
  - Extending a database through an append operation.

POST方法执行的实际功能由服务器决定，通常依赖于Request-URI。发布的实体隶属于该URI，就像文件隶属于包含它的目录，新闻文章隶属于发布它的新闻组，或者记录隶属于数据库一样。

POST方法执行的操作可能不会产生可以由URI标识的资源。在本例中，200 (OK)或204 (No Content)是适当的响应状态，这取决于响应是否包含描述结果的实体。

如果源服务器上已经创建了资源，响应应该是201(已创建)，并包含一个描述请求状态的实体和指向新资源的实体，以及一个Location头(参见14.30节)。

此方法的响应是不可缓存的，除非响应包含适当的Cache-Control或Expires报头字段。然而，303 (See Other)响应可用于指示用户代理检索可缓存资源。

POST请求必须遵守8.2节中规定的消息传输要求。

安全注意事项请参见15.1.3节。

9.6把

The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI. If a new resource is created, the origin server MUST inform the user agent via the 201 (Created) response. If an existing resource is modified, either the 200 (OK) or 204 (No Content) response codes SHOULD be sent to indicate successful completion of the request. If the resource could not be created or modified with the Request-URI, an appropriate error response SHOULD be given that reflects the nature of the problem. The recipient of the entity MUST NOT ignore any Content-* (e.g. Content-Range) headers that it does not understand or implement and MUST return a 501 (Not Implemented) response in such cases.

如果请求经过缓存，而request - uri标识了一个或多个当前缓存的实体，那么这些条目应该被视为过期的。此方法的响应不可缓存。

The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. The URI in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request identifies the entity enclosed with the request -- the user agent knows what URI is intended and the server MUST NOT attempt to apply the request to some other resource. If the server desires that the request be applied to a different URI,

它必须发送一个301(永久移动)响应;用户代理可以自行决定是否重定向请求。

单个资源可以由许多不同的uri标识。例如，一篇文章可能有一个用于标识“当前版本”的URI，它与标识每个特定版本的URI是分开的。在这种情况下，一个通用URI上的PUT请求可能会导致原始服务器定义多个其他URI。

HTTP/1.1没有定义PUT方法如何影响源服务器的状态。

PUT请求必须遵守8.2节中规定的消息传输要求。

除非对特定的实体-头另有指定，否则PUT请求中的实体-头应该应用于PUT创建或修改的资源。

9.7删除

The DELETE method requests that the origin server delete the resource identified by the Request-URI. This method MAY be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation has been carried out, even if the status code returned from the origin server indicates that the action has been completed successfully. However, the server SHOULD NOT indicate success unless, at the time the response is given, it intends to delete the resource or move it to an inaccessible location.

如果响应包含描述状态的实体，那么成功的响应应该是200 (OK)，如果操作尚未实施，则应该是202(已接受)，如果操作已经实施，但响应不包括实体，则应该是204 (No Content)。

如果请求经过缓存，而request - uri标识了一个或多个当前缓存的实体，那么这些条目应该被视为过期的。此方法的响应不可缓存。

1. 恕我直言，你对如何设计你的资源有正确的想法。我什么都不会改变。

2. 不要试图用更多的动词来扩展HTTP，而是考虑您所提议的动词可以根据基本的HTTP方法和资源减少到什么程度。例如，不使用activate_login谓词，可以设置如下资源:/api/users/1/login/active，这是一个简单的布尔值。要激活登录，只需在那里放一个文档，说'true'或1或其他什么。要停用，请在那里放置一个为空或显示为0或false的文档。

类似地，要更改或设置密码，只需对/api/users/1/password执行put。

无论何时你需要添加一些东西(比如信用)，都要考虑post。例如，你可以对类似/api/users/1/credits这样的资源执行POST操作，其主体包含要添加的积分数。同一资源上的PUT操作可以用于覆盖该值而不是添加。主体中带有负数的POST操作将进行减法，以此类推。

3. I'd strongly advise against extending the basic HTTP status codes. If you can't find one that matches your situation exactly, pick the closest one and put the error details in the response body. Also, remember that HTTP headers are extensible; your application can define all the custom headers that you like. One application that I worked on, for example, could return a 404 Not Found under multiple circumstances. Rather than making the client parse the response body for the reason, we just added a new header, X-Status-Extended, which contained our proprietary status code extensions. So you might see a response like:

HTTP/1.1 404 Not Found    
X-Status-Extended: 404.3 More Specific Error Here

这样，像web浏览器这样的HTTP客户端仍然知道如何处理常规的404代码，而更复杂的HTTP客户端可以选择查看X-Status-Extended报头以获得更具体的信息。

4. 对于身份验证，如果可以的话，我建议使用HTTP身份验证。但恕我直言，如果对你来说更容易的话，使用基于cookie的身份验证并没有什么错。

简单地说，你完全是在逆向操作。

你不应该从你应该使用的url来接近它。一旦您决定了系统需要哪些资源，以及如何表示这些资源，以及资源和应用程序状态之间的交互，url将有效地“免费”提供。

引用罗伊·菲尔丁的话

A REST API should spend almost all of its descriptive effort in defining the media type(s) used for representing resources and driving application state, or in defining extended relation names and/or hypertext-enabled mark-up for existing standard media types. Any effort spent describing what methods to use on what URIs of interest should be entirely defined within the scope of the processing rules for a media type (and, in most cases, already defined by existing media types). [Failure here implies that out-of-band information is driving interaction instead of hypertext.]

人们总是从uri开始，并认为这是解决方案，然后他们往往会忽略REST体系结构中的一个关键概念，特别是上面引用的，“这里的失败意味着驱动交互的是带外信息，而不是超文本。”

老实说，很多人看到一堆uri和一些get、put和post，认为REST很简单。REST并不容易。基于HTTP的RPC很容易，通过HTTP有效负载来回移动数据块也很容易。然而，REST不止于此。REST是协议不可知的。HTTP非常流行，适用于REST系统。

REST存在于媒体类型、它们的定义以及应用程序如何通过超文本(实际上是链接)驱动对这些资源可用的操作。

对于REST系统中的媒体类型有不同的看法。一些人喜欢应用程序特定的有效负载，而另一些人喜欢将现有的媒体类型提升到适合应用程序的角色。例如，一方面，您拥有适合应用程序的特定XML模式，而不是使用XHTML之类的东西作为表示(可能是通过微格式或其他机制)。

Both approaches have their place, I think, the XHTML working very well in scenarios that overlap both the human driven and machine driven web, whereas the former, more specific data types I feel better facilitate machine to machine interactions. I find the uplifting of commodity formats can make content negotiation potentially difficult. "application/xml+yourresource" is much more specific as a media type than "application/xhtml+xml", as the latter can apply to many payloads which may or may not be something a machine client is actually interested in, nor can it determine without introspection.

然而，XHTML在web浏览器和呈现非常重要的人类网络中工作得很好(显然)。

您的应用程序将指导您做出此类决定。

REST系统设计过程的一部分是发现系统中的第一类资源，以及派生的支持资源，支持对主要资源的操作所必需的支持资源。一旦发现了资源，那么这些资源的表示以及通过表示中的超文本显示资源流的状态图将成为下一个挑战。

回想一下，在超文本系统中，资源的每种表示都将实际资源表示与资源可用的状态转换结合在一起。将每个资源视为图中的一个节点，链接是将该节点留给其他状态的线。这些链接不仅告诉客户可以做什么，还告诉他们需要做什么(因为一个好的链接结合了URI和所需的媒体类型)。

例如，你可能有:

<link href="http://example.com/users" rel="users" type="application/xml+usercollection"/>
<link href="http://example.com/users?search" rel="search" type="application/xml+usersearchcriteria"/>

您的文档将讨论rel字段名为“users”，媒体类型为“application/xml+youruser”。

这些链接看起来可能是多余的，它们几乎都在与相同的URI通信。但事实并非如此。

这是因为对于“用户”关系，该链接谈论的是用户的集合，您可以使用统一接口来处理集合(GET检索所有用户，DELETE删除所有用户，等等)。

如果您POST到这个URL，您将需要传递一个“application/xml+usercollection”文档，该文档可能只包含一个用户实例，因此您可以添加用户，或者一次添加几个用户。也许您的文档会建议您可以简单地传递单个用户类型，而不是集合。

您可以看到应用程序执行搜索所需的内容(由“search”链接定义)和它的mediatype。搜索媒体类型的文档将告诉您它的行为，以及预期的结果。

不过，这里的要点是uri本身基本上不重要。应用程序控制uri，而不是客户机。除了几个“入口点”，你的客户端应该依赖应用程序提供的uri来工作。

客户端需要知道如何操作和解释媒体类型，但不太需要关心它的去向。

在客户的眼中，这两个链接在语义上是相同的:

<link href="http://example.com/users?search" rel="search" type="application/xml+usersearchcriteria"/>
<link href="http://example.com/AW163FH87SGV" rel="search" type="application/xml+usersearchcriteria"/>

所以，专注于你的资源。关注它们在应用程序中的状态转换，以及如何最好地实现状态转换。

关于REST返回码:将HTTP协议代码和REST结果混淆是错误的。

然而，我看到许多实现混合了它们，许多开发人员可能不同意我的观点。

HTTP返回码与HTTP请求本身相关。REST调用是使用超文本传输协议(Hypertext Transfer Protocol)请求完成的，它的工作级别比调用的REST方法本身要低。REST是一种概念/方法，其输出是业务/逻辑结果，而HTTP结果代码是传输结果。

例如，当你调用/users/时返回“404 Not found”是令人困惑的，因为它可能意味着:

URI错误(HTTP) 没有找到用户(REST)

“403禁止/拒绝访问”可能是指:

需要特别许可。浏览器可以通过询问用户/密码来处理它。(HTTP) 服务器上配置的访问权限错误。(HTTP) 您需要进行身份验证(REST)

这个列表可能会继续出现“500服务器错误”(Apache/Nginx HTTP抛出错误或REST中的业务约束错误)或其他HTTP错误等……

从代码中，很难理解失败的原因是什么，HTTP(传输)失败还是REST(逻辑)失败。

如果HTTP请求物理上被成功执行，它应该总是返回200个代码，不管是否找到记录。因为URI资源是被http服务器找到并处理的。是的，它可能返回一个空集。是否有可能收到一个空网页200作为http结果，对吗?

相反，你可以返回200个HTTP代码和一个带有空数组/对象的JSON，或者使用bool result/success标志来通知所执行的操作状态。

此外，一些互联网提供商可能会拦截您的请求并返回404 http代码。这并不意味着您的数据找不到，而是在传输级别上出了问题。

从维基:

In July 2004, the UK telecom provider BT Group deployed the Cleanfeed content blocking system, which returns a 404 error to any request for content identified as potentially illegal by the Internet Watch Foundation. Other ISPs return a HTTP 403 "forbidden" error in the same circumstances. The practice of employing fake 404 errors as a means to conceal censorship has also been reported in Thailand and Tunisia. In Tunisia, where censorship was severe before the 2011 revolution, people became aware of the nature of the fake 404 errors and created an imaginary character named "Ammar 404" who represents "the invisible censor".