我正在寻找一种方法来包装api的默认功能在我的基于php的web应用程序，数据库和cms。
我环顾四周，发现了几个“骨架”框架。除了我的问题的答案之外，还有一个我喜欢的REST框架Tonic，因为它非常轻量级。
我最喜欢REST，因为它简单，并希望基于它创建一个API体系结构。我正在努力理解基本原理，但还没有完全理解。因此，有一些问题。
1. 我理解得对吗?
假设我有一个资源“用户”。我可以像这样设置一些uri:
/api/users when called with GET, lists users
/api/users when called with POST, creates user record
/api/users/1 when called with GET, shows user record
when called with PUT, updates user record
when called with DELETE, deletes user record
到目前为止，这是RESTful体系结构的正确表示吗?
2. 我需要更多的动词
创建、更新和删除在理论上可能已经足够了，但实际上我需要更多的动词。我知道这些东西可以嵌入到更新请求中，但它们是特定的操作，可以有特定的返回代码，我不想把它们都扔到一个操作中。
在用户示例中想到的一些是:
activate_login
deactivate_login
change_password
add_credit
我该如何表达像RESTful URL体系结构那样的动作呢?
我的直觉是对URL进行GET调用
/api/users/1/activate_login
并等待状态码返回。
但是，这偏离了使用HTTP谓词的想法。你怎么看?
3.如何返回错误消息和代码
A great part of REST's beauty stems from its use of standard HTTP methods. On an error, I emit a header with a 3xx,4xx or 5xx error status code. For a detailed error description, I can use the body (right?). So far so good. But what would be the way to transmit a proprietary error code that is more detailed in describing what went wrong (e.g. "failed to connect to database", or "database login wrong")? If I put it into the body along with the message, I have to parse it out afterwards. Is there a standard header for this kind of thing?
4. 如何进行身份验证
遵循REST原则的基于API密钥的身份验证是什么样子的?
除了公然违反REST原则之外，在验证REST客户机时使用会话是否有强烈的反对之处?:)(这里只是半开玩笑，基于会话的身份验证在我现有的基础设施中可以很好地发挥作用。)
关于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".
几天后我才注意到这个问题，但我觉得我可以补充一些见解。我希望这能对你的平安创业有所帮助。
第一点:我理解得对吗?
你理解得对。这是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作为参数给你资源，在注销时你删除或过期会话。
其他基本知识
REST有一个统一的接口约束，它规定REST客户端必须依赖于标准，而不是实际REST服务的特定于应用程序的细节，因此REST客户端不会因微小的更改而中断，而且可能是可重用的。
因此，REST客户机和REST服务之间存在一个契约。如果您使用HTTP作为底层协议，那么以下标准是合同的一部分:
HTTP 1.1
method definitions
status code definitions
cache control headers
accept and content-type headers
auth headers
IRI (utf8 URI)
body (pick one)
registered application specific MIME type, e.g. maze+xml
vendor specific MIME type, e.g. vnd.github+json
generic MIME type with
application specific RDF vocab, e.g. ld+json & hydra, schema.org
application specific profile, e.g. hal+json & profile link param (I guess)
hyperlinks
what should contain them (pick one)
sending in link headers
sending in a hypermedia response, e.g. html, atom+xml, hal+json, ld+json&hydra, etc...
semantics
use IANA link relations and probably custom link relations
use an application specific RDF vocab
REST有一个无状态约束，它声明REST服务和客户机之间的通信必须是无状态的。这意味着REST服务不能维护客户端状态，因此您不能拥有服务器端会话存储。你必须验证每一个请求。例如，HTTP基本认证(HTTP标准的一部分)是可以的，因为它会在每个请求中发送用户名和密码。
来回答你的问题
是的，它可以是。
值得一提的是，客户端并不关心IRI结构，他们关心的是语义，因为他们遵循具有链接关系或链接数据(RDF)属性的链接。
关于IRI唯一重要的一点是，单个IRI必须只能标识单个资源。允许单个资源(如用户)拥有许多不同的IRIs。
我们使用/users/123/password这样漂亮的IRIs的原因很简单;当你通过阅读IRI来理解它时，在服务器上编写路由逻辑就容易得多了。
你有更多的动词，如PUT, PATCH, OPTIONS，甚至更多，但你不需要更多…而不是添加新的动词，你必须学习如何添加新的资源。
deactivate_login -> PUT /login/active false
change_password -> PUT /user/xy/password "newpass"
add_credit -> POST /credit/raise {details: {}}
(由于无状态约束，从REST的角度来看，登录没有意义。)
您的用户并不关心问题存在的原因。他们只想知道是否有成功或错误，可能是他们能理解的错误消息，例如:“对不起，但我们不能保存您的帖子。”等等……
HTTP状态标头是标准标头。其他的都应该在身体里。例如，单个报头不足以描述详细的多语言错误消息。
The stateless constraint (along with the cache and layered system constraints) ensures that the service scales well. You surely don't wan't to maintain millions of sessions on the server, when you can do the same on the clients...
The 3rd party client gets an access token if the user grants access to it using the main client. After that the 3rd party client sends the access token with every request. There are more complicated solutions, for example you can sign every single request, etc. For further details check the OAuth manual.
相关文献
架构风格与基于网络的软件架构设计
Roy Thomas Fielding博士论文(REST作者)
2000年，加州大学欧文分校
第三代Web api——弥合REST和关联数据之间的差距
Markus Lanthaler博士论文(JSON-LD合著者，Hydra作者)
2014年，奥地利格拉茨理工大学
