An interesting question. I'm finishing up a REST API implementation right now - having used mod_rewrite and PHP. It uses HTTP basic auth across HTTPS. So far we're working on a Palm Pre client. The guy developing that client was a little put off at having to keep track of user credentials to submit with each request.
The idea of exposing SESSION as a resource is an interesting one. Including it would still violate strict RESTful principles. Even if you expose SESSION as a resource, you'd still be using the server to keep track of client state. Strict adherence to REST would probably require use of cookies, as that's the client-side persistent memory available to you from the browser. Problem is that leaves you to create a JavaScript (or FLash?) client to manage the HTTP requests client-side if you don't want users interacting with the browser-implemented gathering of HTTP credentials.
One tool I've found helpful is the REST Client for Firefox tool... but I still enter my credentials into the standard browser popup even when I'm using that.
I have to admit to including some hacks in my implementation. If all you're doing is using sessions to allow for testing/browsing of the API by potential developers or something I don't think that using session-based authentication is such a big deal. Purists would disagree I'm sure. Really that's what this comes down to... this is essentially an academic argument. In real-life situations you have to do what works.
... adding to this on 10/23/2012 ...
The RESTful methodology insistence on making the client keep track of its own state isn't just academic. It has important implications for scalability and the addressability of the exposed resources. When I say this I assume that by client state we are talking about attributes specific to a requesting user which affect the responses issued by the RESTful interface(s). One of REST's strengths is its addressability. When you make its responses in any way dependent on information not passed in the request you start chipping away at that. Just an afterthought... 3 years later, lol.
I know this is a bit of an old question, but I think a lot of the questions here have been addressed in different areas. In particular, I think the OAuth 2.0 Protocol has been considering a lot of these questions; I don't feel authoritative enough to provide a summary of their answers here, but the linked site has a lot of differing use cases called out explicitly, which seems very useful for this question, even if the full OAuth 2.0 isn't really necessary here.
发布评论
评论（2）
一个有趣的问题。 我现在正在完成 REST API 实现 - 使用了 mod_rewrite 和 PHP。 它使用跨 HTTPS 的 HTTP 基本身份验证。 到目前为止，我们正在开发 Palm Pre 客户端。 开发该客户端的人对必须跟踪每个请求提交的用户凭据感到有点犹豫。
将 SESSION 作为资源公开的想法很有趣。 包含它仍然会违反严格的 RESTful 原则。 即使您将 SESSION 作为资源公开，您仍然会使用服务器来跟踪客户端状态。 严格遵守 REST 可能需要使用 cookie，因为这是浏览器提供给您的客户端持久内存。 问题是，如果您不希望用户与浏览器实现的 HTTP 凭据收集进行交互，那么您就需要创建一个 JavaScript（或 FLash？）客户端来管理客户端的 HTTP 请求。
我发现一个有用的工具是 Firefox 的 REST 客户端工具...但即使在使用该工具时，我仍然会在标准浏览器弹出窗口中输入我的凭据。
我必须承认在我的实现中包含了一些技巧。 如果您所做的只是使用会话来允许潜在开发人员测试/浏览 API，或者我认为使用基于会话的身份验证没什么大不了的。 我确信纯粹主义者会不同意。 确实，这就是归结为……这本质上是一个学术争论。 在现实生活中，你必须做有效的事情。
...在 2012 年 10 月 23 日添加此内容...
RESTful 方法论坚持让客户端跟踪自己的状态不仅仅是学术性的。 它对于公开资源的可扩展性和可寻址性具有重要影响。 当我这么说时，我假设通过客户端状态，我们正在讨论特定于请求用户的属性，这些属性会影响 RESTful 接口发出的响应。 REST 的优势之一是其可寻址性。 当您以任何方式根据请求中未传递的信息做出响应时，您就开始削弱它。 只是事后的想法......三年后，哈哈。
An interesting question. I'm finishing up a REST API implementation right now - having used mod_rewrite and PHP. It uses HTTP basic auth across HTTPS. So far we're working on a Palm Pre client. The guy developing that client was a little put off at having to keep track of user credentials to submit with each request.
The idea of exposing SESSION as a resource is an interesting one. Including it would still violate strict RESTful principles. Even if you expose SESSION as a resource, you'd still be using the server to keep track of client state. Strict adherence to REST would probably require use of cookies, as that's the client-side persistent memory available to you from the browser. Problem is that leaves you to create a JavaScript (or FLash?) client to manage the HTTP requests client-side if you don't want users interacting with the browser-implemented gathering of HTTP credentials.
One tool I've found helpful is the REST Client for Firefox tool... but I still enter my credentials into the standard browser popup even when I'm using that.
I have to admit to including some hacks in my implementation. If all you're doing is using sessions to allow for testing/browsing of the API by potential developers or something I don't think that using session-based authentication is such a big deal. Purists would disagree I'm sure. Really that's what this comes down to... this is essentially an academic argument. In real-life situations you have to do what works.
... adding to this on 10/23/2012 ...
The RESTful methodology insistence on making the client keep track of its own state isn't just academic. It has important implications for scalability and the addressability of the exposed resources. When I say this I assume that by client state we are talking about attributes specific to a requesting user which affect the responses issued by the RESTful interface(s). One of REST's strengths is its addressability. When you make its responses in any way dependent on information not passed in the request you start chipping away at that. Just an afterthought... 3 years later, lol.
我知道这是一个有点老的问题，但我认为这里的很多问题已经在不同的领域得到了解决。 特别是，我认为 OAuth 2.0 协议已经考虑了很多这些问题； 我觉得没有足够的权威来在这里提供他们的答案的摘要，但是链接的网站有很多明确指出的不同用例，这对于这个问题似乎非常有用，即使完整的 OAuth 2.0 并不是真正必要的这里。
I know this is a bit of an old question, but I think a lot of the questions here have been addressed in different areas. In particular, I think the OAuth 2.0 Protocol has been considering a lot of these questions; I don't feel authoritative enough to provide a summary of their answers here, but the linked site has a lot of differing use cases called out explicitly, which seems very useful for this question, even if the full OAuth 2.0 isn't really necessary here.