RESTdevise/login或/注册资源？

我正在devise一个Web应用程序，然后停下来考虑如何将我的APIdevise为一个REST风格的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和谷歌。

以/logout ，也许因为我没有真正获得任何东西 – 将请求发送到/logout ，销毁会话，然后GETredirect可能更合适。 应该/logout期保持？

怎么样/login和/register 。 我可以更改/register /registration但这并不会改变我的服务从根本上起作用 – 如果它有更深的问题。

我现在注意到，我从来没有公开一个/user资源。 也许这可以用某种方式来利用。 例如，用户myUser ：

 foo.com/user/myUser 

要么

 foo.com/user 

最终用户在URI中不需要额外的冗长。 但是，哪一个更吸引人的视觉呢？

我在这里注意到关于这个REST业务的其他一些问题，但是如果可能的话，我会非常感谢一些关于我已经在这里列出的指导。

谢谢！

更新：

我还想就以下几点提出意见：

 /user/1 

VS

 /user/myUserName 

Answer 1

有一点特别突出，因为不是REST-ful：使用GET请求注销。

（来自http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Safe_methods ）

有些方法（例如，HEAD，GET，OPTIONS和TRACE）被定义为安全的，这意味着它们仅用于信息检索，不应该改变服务器的状态。 换句话说，他们不应该有副作用，除了相对无害的影响，如日志logging，caching，横幅广告的投放或增加networking计数器。 […]

[… H]和服务器[GET请求]在技术上没有任何限制。 因此，粗心或故意的编程可能会导致服务器上不小的更改。 这是令人沮丧的，因为它可能会导致Webcaching，search引擎和其他自动化代理问题[…]

至于注销和redirect，您可以在注销URI中添加一条post，让303响应redirect到注销后页面。

http://en.wikipedia.org/wiki/Post/Redirect/Get

http://en.wikipedia.org/wiki/HTTP_303

编辑以解决URLdevise问题：

“我如何devise我的资源？” 对我来说是一个重要的问题。 “我如何devise我的url？” 是两个方面的考虑：

如果可能的话，用户将看到的URL不应该太丑陋和有意义; 如果你想要cookie发送请求到一些资源，但不是其他的，你会想要构build你的path和cookiepath。

如果JRandomUser想要查看他自己的configuration文件，并且希望URL比foo.com/user/JRandomUser或foo.com/user/(JRandom's numeric user id here)漂亮，则可以为用户创build单独的URL看看自己的信息：

 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. */ 

在这个问题上，我会比智慧更容易宣称无知，但是这里有一些资源devise考虑因素：

1. 消费者：哪些资源是直接在浏览器中查看，通过XHR加载，还是由其他types的客户端访问？
2. 访问/身份：响应取决于Cookie或推荐人？

Answer 2

可以使用RESTful作为构buildURL的指南，并且可以创build会话和用户资源：

• GET /session/new获取具有login表单的网页
• POST /session根据数据库validation凭据
• DELETE /session破坏会话并redirect到/
• GET /users/new获取具有registry单的网页
• POST /users将input的信息作为新/ user / xxxlogging到数据库中
• GET /users/xxx //在configuration文件视图中获取并呈现当前用户数据
• POST /users/xxx //更新有关用户的新信息

这些可以是复数或单数（我不知道哪一个是正确的）。 我通常使用/users的用户索引页面（如预期的）和/sessions ，看看谁login（如预期）。

在URL中使用名称而不是数字（ /users/43 vs. /users/joe ）通常是由于希望对用户或search引擎更友好，而不是任何技术要求。 要么是好的，但我build议你是一致的。

我想如果你使用register / login / logout或sign(in|up|out) ，那么和restful的术语不一样。

Answer 3

会话不是RESTful

• 是的我知道。 正在完成，通常使用OAuth，但实际上会话不是RESTful。 你不应该有一个/login/注销资源，主要是因为你不应该有会议。

• 如果你打算这样做，使它RESTful。 资源是名词和/login和/注销不是名词。 我会去/会议。 这使创build和删除更自然的行动。

• POST和GET会话很简单。 如果你发送用户/密码作为variables，我会使用POST，因为我不想让密码作为URI的一部分发送。 它会显示在日志中，可能会暴露在电线上。 您也有运行GET参数限制软件失败的风险。

• 我通常使用基本身份validation或不使用REST服务的身份validation。

创build用户

• 这是一个资源，所以你不应该需要/注册。

  • POST / user – 如果请求者不能指定id，则创build一个用户
  • PUT / user / xxx – 假设您事先知道id，请创build或更新用户
  • GET / user – 列出x个用户ID
  • GET / user / xxx – 获取id为xxx的用户的详细信息
  • DELETE / user / xxx – 删除ID为xxx的用户

• 使用哪种ID是一个难题。 你必须考虑强制执行唯一性，重新使用被删除的旧ID。 例如，如果id将被回收（如果可能的话），您不希望将这些id用作后端的外键。 您可以通过查找外部/内部id转换来缓解后端需求。

Answer 4

无论是用于移动应用程序还是用于服务器到服务器的通信，以及为其他人构buildREST API，我都将简单介绍为我的客户集成各种REST Web服务的经验。 以下是我从其他人的REST API以及我们自己构build的这些观察结果：

• 当我们说API时，通常是指一组编程接口而不需要表示层。 REST也是以数据为中心的，而不是演示文稿驱动的。 这就是说大多数REST以JSON或XML的forms返回数据，很less返回特定的表示层。 这个特性（返回的数据而不是直接的网页）给予REST能力做多通道传递。 这意味着相同的web服务可以在HTML，iOS，Android中呈现，甚至可以用作服务器到服务器的组合。
• 将HTML和REST作为URL组合非常罕见。 默认情况下，REST是作为服务的思想，没有表示层。 对于那些使用Web服务的人来说，根据他们想要的来调用他们所调用的服务的数据是一项工作。 到目前为止，您的URL不符合我迄今为止遇到的大多数基于REST的devise（也不符合来自Facebook或Twitter的标准）

 GET / register //获取具有registry单的网页

• 从以前的观点来看，对于基于REST的服务来做redirect也是不常见的（而且我还没遇到过），比如下面的build议：

 GET /注销/ /破坏会议和redirect到/
 POST / login //根据数据库validation凭据，并redirect到新的会话或redirect回/login
 

由于REST被devise为服务，因此login和注销等function通常会返回成功/失败结果（通常采用JSON或XML数据格式），然后由用户来解释。 这种解释可能包括redirect到适当的网页，如你所说

• 在REST中，URL表示所采取的操作。 出于这个原因，我们应该消除尽可能多的歧义。 虽然在您的情况下，具有相同path（例如/ register）的GET和POST都执行不同的操作是合法的，但这样的devise会在所提供的服务中引入歧义，并可能会混淆服务的使用者。 例如，下面介绍的URL不适用于基于REST的服务

 GET / register //获取具有registry单的网页
 POST / register //将input的信息作为新的/ user / xxxlogging到数据库中

这些是我所处理的一些问题。 我希望它能为你提供一些见解。

现在就实现您的REST来说，这些是我遇到的典型实现：

•  GET /注销  
  

  在后端执行注销并返回JSON以表示操作的成功/失败

•  POST /login
  

  提交凭据到后端。 返回成功/失败。 如果成功，通常还会返回会话令牌以及configuration文件信息。

•  POST /注册
  

  提交注册到后端。 返回成功/失败。 如果成功，通常被视为成功login相同，或者您可以select注册为一个独特的服务

•  GET / user / xxx
  

  获取用户configuration文件并返回用户configuration文件的JSON数据格式

•  POST / user / xxx 
   //重命名为 
   POST / updateUser / xxx
  

  以JSON格式发布更新的configuration文件信息并更新后端的信息。 返回成功/失败的来电者

Answer 5

使用和deviseAPI并不是关于视觉吸引力的 URL，而是有意义的URL。 对于用户注册/login，我已经使用过这些：

 GET /user // Get multiple user info (limit ~10) GET /user/1 // Get single user info POST /user // Create user (registration) PUT /user/1 // Edit user POST /user/1/login // Login (could be GET, but I like sending more secure params by POST) GET /user/1/logout // Logout 

Answer 6

我build议使用类似于twitter的用户帐户URL，其中用户的帐户url将类似于foo.com/myUserName ，就像您可以通过URL https://twitter.com/joelbyler访问我的Twitter帐户一样;

我不同意注销需要一个POST。 作为API的一部分，如果要维护一个会话，那么会以UUID的forms显示一个会话ID，可能会用来跟踪用户并确认所采取的操作是否已被授权。 然后，甚至一个GET可以将会话ID传递给资源。

总之，我会build议你保持简单，URL应该是一个难忘的。

Answer 7

我相信这是一个RESTfulauthentication的方法。 对于LogIn，您使用HttpPut 。 这个HTTP方法可以在提供密钥时用于创build，并且重复的调用是幂等的。 对于LogOff，您可以在HttpDelete方法下指定相同的path。 没有使用动词。 适当的收集多元化。 HTTP方法支持这个目的。

 [HttpPut] [Route("sessions/current")] public IActionResult LogIn(LogInModel model) { ... } [HttpDelete] [Route("sessions/current")] public IActionResult LogOff() { ... } 

如果需要的话，你可以用电stream代替激活。