RESTfully设计/login或/register资源？
我正在设计一个web应用程序，然后停下来思考如何将我的应用程序接口设计为一个RESTful web服务。目前，我的大多数URI都是通用的，可能适用于各种web应用程序：
GET /logout // destroys session and redirects to /
GET /login // gets the webpage that has the login form
POST /login // authenticates credentials against database and either redirects home with a new session or redirects back to /login
GET /register // gets the webpage that has the registration form
POST /register // records the entered information into database as a new /user/xxx
GET /user/xxx // gets and renders current user data in a profile view
POST /user/xxx // updates new information about user在浏览了SO和google之后，我有一种感觉，我在这里做了很多错误的事情。
从/logout开始，也许因为我并不是真的GET任何东西- POST到/logout的请求，销毁会话，然后GET重定向可能更合适。/logout这个术语应该保留下来吗？
那/login和/register呢？我可以将/register更改为/registration，但这不会改变我的服务的基本工作方式--如果它有更深层次的问题的话。
我现在注意到我从来没有公开过/user资源。也许这可以以某种方式加以利用。例如，以用户myUser为例
foo.com/user/myUser或
foo.com/user最终用户不需要在URI中提供额外的详细信息。然而，哪一个在视觉上更吸引人？
我在这里注意到了一些关于REST业务的其他问题，但如果可能的话，我将非常感谢关于我在这里列出的内容的一些指导。
谢谢!
更新：
我也想就以下几点提出一些意见：
/user/1vs
/user/myUserName回答 5
Stack Overflow用户
发布于 2011-08-30 22:36:35
有一件事特别突出，因为它不是REST-ful:使用GET请求注销。
(来自http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Safe_methods)
某些方法(例如HEAD、GET、OPTIONS和TRACE)被定义为安全的，这意味着它们仅用于信息检索，不应更改服务器的状态。换句话说，它们不应该有副作用，除了相对无害的影响，如日志记录、缓存、提供横幅广告或递增web计数器。服务器对GET请求的...andling没有任何技术上的限制。因此，粗心或刻意的编程可能会在服务器上造成很大的变化。不鼓励这样做，因为它会给Web缓存、搜索引擎和其他自动化代理带来问题……
至于注销和重定向，您可以对注销URI进行post，给出一个303响应，重定向到注销后的页面。
http://en.wikipedia.org/wiki/Post/Redirect/Get
http://en.wikipedia.org/wiki/HTTP_303
编辑以解决URL设计问题：
“如何设计我的资源？”对我来说是一个重要的问题：“我如何设计我的URL？”是两个方面的考虑：
如果可能的话，用户看到的URL不应该太难看，也不应该太有意义；如果您希望在请求中将cookie发送到某些资源，而不是其他资源，则需要构造路径和cookie路径。
如果JRandomUser想要查看他自己的个人资料，而你又想让网址比foo.com/user/JRandomUser或foo.com/user/(JRandom's numeric user id here)更漂亮，你可以制作一个单独的网址供用户查看他们自己的信息：
GET foo.com/profile /*examines cookies to figure out who
* is logged in (SomeUser) and then
* displays the same response as a
* GET to foo.com/users/SomeUser.
*/在这个问题上，我更容易声称自己一无所知，而不是智慧，但这里有一些资源设计方面的考虑：
cookies消费者:哪些资源应该直接在浏览器中查看、通过XHR加载或通过某种其他类型的client?
- Access /
- 访问:响应依赖于cookies还是referrers?
Stack Overflow用户
发布于 2011-08-31 11:39:39
RESTful可以作为构建URL的指导原则，您可以创建会话和用户资源：
GET /session/new获取具有登录表单的网页POST /session针对databaseDELETE /session验证凭据销毁会话并重定向到/GET /users/new获取具有注册的网页formPOST /users将输入的信息记录到数据库中作为新的/user/xxxGET /users/xxx//在配置文件中获取和呈现当前用户数据viewPOST /users/xxx//更新有关用户的新信息
它们可以是复数也可以是单数(我不确定哪一个是正确的)。我通常使用/users作为用户索引页面(不出所料)，使用/sessions查看登录的用户(不出所料)。
在网址中使用名称而不是数字(/users/43与/users/joe)通常是出于对用户或搜索引擎更友好的愿望，而不是任何技术要求。任何一种都可以，但我建议你保持一致。
我认为如果您使用注册/登录/注销或sign(in|up|out)，那么它在restful术语中就不能很好地工作。
Stack Overflow用户
发布于 2011-09-01 00:50:19
会话不是RESTful
- 是的，我知道。这是正在做的，通常是使用OAuth，但实际上会话不是RESTful。您不应该拥有/login /logout资源，主要是因为您不应该拥有会话。
- 如果你要做这件事，就让它成为RESTful。资源是名词，而/login和/logout不是名词。我会选择/session。这使得创建和删除变得更加自然。
- 的POST和GET会话很容易。如果您将user/password作为变量发送，我将使用POST，因为我不希望将密码作为URI的一部分发送。它将显示在日志中，并可能通过网络暴露出来。您还面临着软件在GET args限制下失败的风险。
- I通常对REST服务使用基本身份验证或无身份验证。
创建用户
- 这是一种资源，所以你不应该需要/register。
- POST /user - Creates a user if the requestor cannot specify the id
- PUT /user/xxx - Create or update a user assuming you know the id beforehand
- GET /user - lists x user ids
- GET /user/xxx - GETs the details of the user with id xxx
- DELETE /user/xxx - Delete the user with id xxx
- 使用哪种ID是一个很难回答的问题。您必须考虑强制唯一性，重用旧的ids，这些ids是DELETEd。例如，如果ids将被回收(如果可能的话)，您不希望将这些ids用作后端上的外键。您可以查找外部/内部id转换，以减少后端requirements.
https://stackoverflow.com/questions/7140074
复制相似问题