RESTful дизайн / логин или / регистрация ресурсов?

RESTful может использоваться как ориентир для создания URL-адресов, и вы можете создавать сеансы и ресурсы пользователей:

• GET /session/new получает веб-страницу с формой входа
• POST /session аутентифицирует учетные данные для базы данных
• DELETE /session уничтожает сеанс и перенаправляет на /
• GET /users/new получает веб-страницу с регистрационной формой
• POST /users записывает введенную информацию в базу данных как новый /user/xxx
• GET /users/xxx//получает и отображает текущие пользовательские данные в представлении профиля
• POST /users/xxx//обновляет новую информацию о пользователе

Они могут быть множественными или единственными (я не уверен, какой из них правильный). Обычно я использовал /users для пользовательской индексной страницы (как и ожидалось) и /sessions, чтобы узнать, кто вошел в систему (как и ожидалось).

Использование имени в URL вместо числа (/users/43 vs. /users/joe) обычно обусловлено желанием быть более дружелюбным к пользователям или поисковым системам, а не к каким-либо техническим требованиям. Все в порядке, но я бы рекомендовал вам быть последовательным.

Я думаю, что если вы пойдете с регистром /login/logout или sign(in|up|out), это не сработает с успокоительной терминологией.

Сеансы не RESTful

• Да, я знаю. Это делается, как правило, с OAuth, но на самом деле сеансы не RESTful. Вы не должны иметь ресурс /login/logout, потому что у вас не должно быть сеансов.

• Если вы собираетесь это сделать, сделайте его RESTful. Ресурсы - существительные и /login и/logout - не существительные. Я бы пошел с /session. Это делает создание и удаление более естественным действием.

• POST и GET для сеансов легко. Если вы отправляете пользователя/пароль в качестве переменных, я бы использовал POST, потому что я не хочу, чтобы пароль был отправлен как часть URI. Он появится в журналах и, возможно, будет выставлен по проводам. Вы также рискуете, что программное обеспечение завершится с ошибкой GET args.

• Обычно я использую Basic Auth или no Auth с сервисами REST.

Создание пользователей

• Это один ресурс, поэтому вам не нужно/зарегистрироваться.

  • POST/user - создает пользователя, если запрашивающий не может указать идентификатор
  • PUT/user/xxx - Создайте или обновите пользователя, если вы заранее знаете идентификатор.
  • GET/user - список x идентификаторов пользователей
  • GET/user/xxx - ПОЛУЧИТ детали пользователя с идентификатором xxx
  • DELETE/user/xxx - Удалить пользователя с идентификатором xxx

• Какой тип идентификатора используется, это сложный вопрос. Вы должны думать об обеспечении уникальности, о повторном использовании старых идентификаторов, которые были DELETEd. Например, вы не хотите использовать эти идентификаторы как внешние ключи на бэкэнд, если идентификаторы будут переработаны (если это вообще возможно). Однако для внешнего/внутреннего преобразования идентификаторов вы можете искать, чтобы уменьшить требования к бэкэнд.

Я просто расскажу о своем опыте интеграции различных веб-сервисов REST для своих клиентов, будь то для мобильных приложений или для связи между серверами и серверами, а также для создания REST API для других. Вот несколько замечаний, которые я собрал из других REST API других людей, а также те, которые мы создали сами:

• Когда мы говорим API, он обычно относится к набору программных интерфейсов, а не к уровню представления. REST также ориентирован на данные, а не ориентирован на презентацию. Тем не менее большинство REST возвращают данные в виде JSON или XML и редко возвращают определенный уровень представления. Эта характеристика (возврата данных, а не прямой веб-страницы) дает возможность REST выполнять многоканальную доставку. Это означает, что один и тот же веб-сервис может отображаться в формате HTML, iOS, Android или даже использоваться как комбинация серверов и серверов.
• Очень редко комбинировать как HTML, так и REST в качестве URL-адреса. По умолчанию REST - это мысли как службы и не имеющие уровня представления. Это работа для тех, кто потребляет веб-службы для предоставления данных из услуг, которые они называют, в соответствии с тем, что они хотят. К тому моменту ваш URL-адрес ниже соответствует большинству проектов, основанных на REST, которые я встречал до сих пор (а также стандарты, такие как те, которые поступают из Facebook или Twitter).

GET  /register // gets the webpage that has the registration form

• Продолжая предыдущую точку, также редко (и я не встречался) для службы на основе REST для перенаправления, такой как предложенные ниже:

GET  /logout   // destroys session and redirects to /
POST /login    // authenticates credentials against database and either redirects home with a new session or redirects back to /login
 

Поскольку REST разрабатываются как службы, такие функции, как вход и выход из системы, обычно возвращают результат успеха/отказа (обычно в формате JSON или XML), который затем потребитель интерпретирует. Такая интерпретация может включать перенаправление на соответствующую веб-страницу, как вы упомянули

• В REST URL означает действия, которые были предприняты. По этой причине мы должны устранить как можно большую двусмысленность. Хотя в вашем случае законно иметь GET и POST, которые имеют один и тот же путь (например,/register), которые выполняют разные действия, такой дизайн вводит двусмысленность в предоставляемых услугах и может запутать потребителя ваших услуг. Например, такие URL-адреса, как тот, который вы вводите ниже, не являются идеальными для служб на основе REST.

GET  /register // gets the webpage that has the registration form
POST /register // records the entered information into database as a new /user/xxx

Вот некоторые моменты из того, что я имел в виду. Я надеюсь, что это может дать вам некоторые идеи.

Теперь, насколько это возможно для реализации вашего REST, это типичная реализация, с которой я столкнулся:

• GET  /logout  
  

  Выполнить выход в бэкэнд и вернуть JSON для обозначения успеха/отказа операции

• POST /login
  

  Отправьте учетные данные на сервер. Возвратите успех/неудачу. В случае успеха обычно он также возвращает токен сеанса, а также информацию профиля.

• POST /register
  

  Подать заявку на бэкэнд. Возвратите успех/неудачу. В случае успеха обычно обрабатывается то же самое, что и успешный вход в систему, или вы можете выбрать регистрацию в качестве отдельной службы.

• GET  /user/xxx
  

  Получить профиль пользователя и вернуть формат данных JSON для профиля пользователя

• POST /user/xxx 
  // renamed to 
  POST /updateUser/xxx
  

  Опубликовать обновленную информацию о профиле как формате JSON и обновить информацию в бэкэнд. Вернуть успех/отказ вызывающему абоненту

Использование и разработка API-интерфейсов - это не только визуально привлекательные URL-адреса, но и URL-адреса, которые имеют смысл. Для регистрации пользователя/входа в систему я использовал их в прошлом:

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

Я считаю, что это подход RESTful к аутентификации. Для LogIn вы используете HttpPut. Этот метод HTTP может использоваться для создания, когда ключ предоставляется, а повторные вызовы являются идемпотентными. Для LogOff вы указываете тот же путь в методе HttpDelete. Нет глаголов. Надлежащая коллективная плюрализация. Методы HTTP поддерживают цель.

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

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

При желании вы можете заменить ток на активный.

Я бы рекомендовал использовать URL-адрес учетной записи пользователя, похожий на твиттер, где URL-адрес учетной записи пользователя был бы похож на foo.com/myUserName так же, как вы можете попасть в мою учетную запись Twitter с URL https://twitter.com/joelbyler

Я не согласен с выходом из системы, требующей POST. Как часть вашего API, если вы собираетесь поддерживать сеанс, тогда идентификатор сеанса в форме UUID может быть тем, что можно использовать для отслеживания пользователя и подтверждения того, что действие, которое принято, разрешено. Тогда даже GET может передать идентификатор сеанса на ресурс.

Короче говоря, я бы порекомендовал вам сохранить его простым, URL-адрес должен быть незабываемым.