Как открыть API проверки подлинности с помощью RESTful?

Я вообще поклонник дизайна RESTful API, но я не уверен, как применять принципы REST для API проверки.

Предположим, у нас есть API для запроса и обновления информации профиля пользователя (имя, адрес электронной почты, имя пользователя, пароль). Мы считали, что полезная функциональность для раскрытия будет проверкой, например. запрос, является ли данное имя пользователя действительным и доступным.

Каков ресурс в этом случае? Какие коды состояния HTTP и/или заголовки должны использоваться?

В качестве начала у меня есть GET /profile/validate, который принимает параметры строки запроса и возвращает 204 или 400, если он действителен или недействителен. Но validate - это, очевидно, глагол, а не существительное.

ОТВЕТЫ

Ответ 1

Тип вещи, о котором вы описали, является, безусловно, более RPC-стилем в его "семантике", но это не значит, что вы не можете достичь своих целей в RESTful.

Там нет VALIDATE HTTP-глагола, так, сколько значения вы можете получить от структурирования всего API вокруг этого? Ваша история сосредотачивается вокруг предоставления пользователям возможности определять, доступно ли данное имя пользователя - это звучит для меня как простая проверка ресурса - GET: /profile/username/... - если результатом является 404, имя доступно.

Что это подчеркивает, так это то, что проверка на стороне клиента - это только клиентская сторона. Это проблема пользовательского интерфейса, чтобы гарантировать, что данные будут проверены на клиенте перед отправкой на сервер. Служба RESTful не дает ничего, независимо от того, выполнил ли клиент проверку; он просто примет или отклонит запрос на основе его собственной логики проверки.

REST не является всеобъемлющей парадигмой, он описывает только способ структурирования коммуникаций клиент-сервер.

Ответ 2

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

Наш первый шаг состоял в том, чтобы реализовать объект метаданных, который можно запросить из службы метаданных (GET /metadata/user). Этот объект метаданных затем используется, чтобы сообщить клиенту, как выполнять основные проверки на стороне клиента (обязательность, тип, длина и т.д.). Мы генерируем большинство из них из нашей базы данных.

Вторая часть состоит из добавления нового ресурса, называемого анализом. Например, если у нас есть служба:

GET /users/100

Мы создадим новый ресурс, называемый:

POST /users/100/analysis

Ресурс анализа содержит не только любые ошибки проверки, которые произошли, но также и статистическую информацию, которая может быть актуальной, если это необходимо. Одна из проблем, которые мы обсуждали, заключалась в том, какой глагол использовать для ресурса анализа. Мы пришли к выводу, что это должен быть POST, поскольку анализ создается во время запроса. Тем не менее, у GET были серьезные аргументы.

Надеюсь, это полезно для других, пытающихся решить эту же проблему. Любые отзывы об этом дизайне приветствуются.

Ответ 3

Вы путаете REST с ориентацией ресурсов, в REST нет ничего, что говорит, что вы не можете использовать глаголы в URL-адресах. Когда дело доходит до дизайна URL, я обычно выбираю то, что является наиболее самоописательным, wheoun - существительное или глагол.

О вашей службе, что я буду делать, это использовать тот же ресурс, который вы используете для обновления, но с параметром querystring test, поэтому, когда test=1 операция не выполняется, но вы можете использовать ее для возврата ошибок проверки.

PATCH /profile?test=1
Content-Type: application/x-www-form-urlencoded

dob=foo

... и ответ:

HTTP/1.1 400 Bad Request
Content-Type: text/html

<ul class="errors">
  <li data-name="dob">foo is not a valid date.</li>
</ul>

Ответ 4

Приветствуем, что в API REST есть подтверждение. В любом случае вам нужна проверка, и вы не будете использовать ее на стороне клиента. В моем случае у меня просто есть соглашение в API, что специальный error_id представляет ошибки проверки, а в error_details имеется массив сообщений об ошибках для каждой группы, у которой есть ошибки в этом вызове PUT или POST. Для справки:

{
  "error": true,
  "error_id": 20301,
  "error_message": "Validation failed!",
  "error_details": {
    "number": [
      "Number must not be empty"
    ],
    "ean": [
      "Ean must not be empty",
      "Ean is not a valid EAN"
    ]
  }
}

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

И вот как это выглядит в приложении для мобильных устройств: введите описание изображения здесь

Ответ PUT или POST используется для отображения сообщений об ошибках для каждого поля. Это тот же вызов из веб-приложения с использованием команды React: введите описание изображения здесь

Таким образом, все ответные коды REST API, такие как 200, 404, имеют значение, как они должны. Ответы PUT на вызов 200, даже если проверка не выполняется. Если проверка пароля проходит, ответ будет выглядеть так:

{
  "error": false,
  "item": {
"id": 1,
"created_at": "2016-08-03 13:58:11",
"updated_at": "2016-11-30 08:55:58",
"deleted_at": null,
"name": "Artikel 1",
"number": "1273673813",
"ean": "12345678912222"
  }
}