Путаница между существительным и глаголом в URL-адресах останова

Я изучил через Интернет о restful APIs, что он сосредоточен на существительных, а не глаголах в шаблоне url, но теперь я вижу несколько ссылок, которые используют глаголы в URL.

Вот пример.

  • POST/v1/payments/authorization/< Authorization-Id > /capture
  • POST/v1/payments/authorization/< Authorization-Id > /void
  • POST/v1/payments/authorization/< авторизация-Id & reauthorize

это Paypal apis. API PayPal

также на wikipedia на странице HTATEOAS они привезли пример;

<?xml version="1.0"?>
<account>
   <account_number>12345</account_number>
   <balance currency="usd">100.00</balance>
   <link rel="deposit" href="/account/12345/deposit" />
   <link rel="withdraw" href="/account/12345/withdraw" /> 
   <link rel="transfer" href="/account/12345/transfer" />
   <link rel="close" href="/account/12345/close" />
 </account>

ссылка: Wiki HATEOAS

Может ли кто-нибудь помочь мне получить некоторую ясность по этому поводу? почему "захват", "пустота", "депозит", "вывод", "закрытие" находятся в URI, потому что все глаголы не являются существительными?

или это нормально использовать эти слова в полном порядке apis url?

ОТВЕТЫ

Ответ 1

Некоторые фрагменты из Rule API Rulebook о разных типах ресурсов:

Документ

Ресурс документа - это уникальная концепция, которая сродни экземпляру объекта или базе данных запись.

Пример:     http://api.soccer.restapi.org/leagues/seattle/teams/trebuchet

Collection

Ресурс коллекции - это управляемый сервером каталог ресурсов. Клиенты могут предлагать новые ресурсы, которые будут добавлены в коллекцию. Однако выбор зависит от выбора для создания нового ресурса или нет.

Пример: http://api.soccer.restapi.org/leagues/seattle/teams

Магазин

Магазин - это репозиторий ресурсов, управляемый клиентом. Ресурс магазина позволяет клиенту API ресурсы, вернуть их и решить, когда их удалять. Собственные магазины не создавать новые ресурсы; поэтому магазин никогда не генерирует новые URI. Вместо этого каждый хранимый ресурс имеет URI, который был выбран клиентом, когда он был первоначально помещен в магазин.

Пример: PUT /users/1234/favorites/alonso

контроллер

Ресурс контроллера моделирует процедурную концепцию. Ресурсы контроллера похожи на исполняемые функции с параметрами и возвращаемыми значениями; входы и выходы.

Как и традиционные веб-приложения, использующие HTML-формы, REST API полагается на контроллер ресурсов для выполнения действий, специфичных для приложения, которые невозможно логически сопоставить с один из стандартных методов (создание, извлечение, обновление и удаление, также известный как CRUD).

Имена контроллеров обычно отображаются как последний сегмент в пути URI, без дочернего ресурсов, чтобы следовать им в иерархии.

Пример: POST /alerts/245743/resend

Основываясь на определениях в книге, URI, которые вы опубликовали, вероятно, относятся к типу ресурса Контроллер, о котором позже говорится в книге:

Правило: для имен контроллеров следует использовать глагольную или глагольную фразу

Примеры:

  • http://api.college.restapi.org/students/morgan/register
  • http://api.example.restapi.org/lists/4324/dedupe
  • http://api.ognom.restapi.org/dbs/reindex
  • http://api.build.restapi.org/qa/nightly/runTestSuite

Другие правила именования, только для полноты

  • Правило: для имен документов следует использовать уникальное существительное
  • Правило: множественное число существительное должно использоваться для имен коллекции
  • Правило: множественное число существительное должно использоваться для имен магазинов

Ответ 2

В REST глагол используется метод HTTP. В вашем примере это POST, но также может быть GET, PUT или DELETE.

существительное - это ресурс, идентифицированный URL-адресом. В вашем примере "существительные" /v1/payments/authorization/<Authorization-Id>/capture и т.д.

Как вы можете видеть, это не действительно существительное, так как capture - это глагол: захват авторизации платежа. Это не RESTful, поскольку это команда, глагол, а не вещь, существительное.

Лучше всего было бы моделировать эти команды как вещи, такие как /v1/payments/authorization/<Authorization-Id>/capturecommand. Эта команда будет вещью, существительным. Он может иметь состояние, например, если оно было успешным, каков был результат и т.д.

Существует много кода, который утверждает, что он RESTful и не работает.

Ответ 3

Трюк состоит в том, чтобы сделать все существительные (или сущности), которые работают с глаголами CRUD.

Итак, вместо <

POST /v1/payments/authorization/<Authorization-Id>/capture
POST /v1/payments/authorization/<Authorization-Id>/void
POST /v1/payments/authorization/<Authorization-Id>/reauthorize

Сделайте это;

capture -> POST /v1/payments/authorization/<Authorization-Id>
void    -> DELETE /v1/payments/authorization/<Authorization-Id>
reauthorize -> delete first then create again.