我正在寻找一种方法来包装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客户机时使用会话是否有强烈的反对之处?:)(这里只是半开玩笑，基于会话的身份验证在我现有的基础设施中可以很好地发挥作用。)
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的身份验证并没有什么错。
回复1:到目前为止看起来还不错。记住在“Location:”报头中返回新创建用户的URI，作为对POST的响应的一部分，同时返回“201 created”状态码。
re 2: Activation via GET is a bad idea, and including the verb in the URI is a design smell. You might want to consider returning a form on a GET. In a Web app, this would be an HTML form with a submit button; in the API use case, you might want to return a representation that contains a URI to PUT to to activate the account. Of course you can include this URI in the response on POST to /users, too. Using PUT will ensure your request is idempotent, i.e. it can safely be sent again if the client isn't sure about success. In general, think about what resources you can turn your verbs into (sort of "nounification of verbs"). Ask yourself what method your specific action is most closely aligned with. E.g. change_password -> PUT; deactivate -> probably DELETE; add_credit -> possibly POST or PUT. Point the client to the appropriate URIs by including them in your representations.
re 3. Don't invent new status codes, unless you believe they're so generic they merit being standardized globally. Try hard to use the most appropriate status code available (read about all of them in RFC 2616). Include additional information in the response body. If you really, really are sure you want to invent a new status code, think again; if you still believe so, make sure to at least pick the right category (1xx -> OK, 2xx -> informational, 3xx -> redirection; 4xx-> client error, 5xx -> server error). Did I mention that inventing new status codes is a bad idea?
re 4. If in any way possible, use the authentication framework built into HTTP. Check out the way Google does authentication in GData. In general, don't put API keys in your URIs. Try to avoid sessions to enhance scalability and support caching - if the response to a request differs because of something that has happened before, you've usually tied yourself to a specific server process instance. It's much better to turn session state into either client state (e.g. make it part of subsequent requests) or make it explicit by turning it into (server) resource state, i.e. give it its own URI.
