RESTful API для POST, когда пути других глаголов HTTP имеют несколько параметров? - PullRequest
Новая
       8

RESTful API для POST, когда пути других глаголов HTTP имеют несколько параметров?

0 голосов
/ 15 января 2019

Привет и счастливого января!

Просматривая недавно созданный очень простой RESTful API, мне интересно, сделал ли я подпись RESTful API для его POST.

Этот RESTful API запрашивает очень простую коллекцию MongoDB Apps, и ее столбцы:

  • _id, (appId)
  • siteId (обязательно)
  • accountId (обязательно)
  • provider (обязательно)
  • description

Индекс:

  • provider, siteId, accountId: unique

Структура данных:

  • Каждый сайт (siteId) имеет несколько учетных записей (accountId).
  • Каждая учетная запись (accountId) имеет несколько приложений (appId).

Пути для HTTP-глаголов GET DELETE и PATCH, обрабатывающих элементы в коллекции Apps:

  • GET /api/v1/sites/:siteId/accounts/:accountId/apps
  • DELETE /api/v1/sites/:siteId/accounts/:accountId/apps
  • PATCH /api/v1/sites/:siteId/accounts/:accountId/apps

Мое затруднение заключается в следующем: я хочу POST новое приложение, которое будет связано с siteId + accountId.

Мне интересно, имеет ли смысл то, как я определил этот путь POST, потому что новое приложение может добавлять в эту коллекцию либо siteId, либо accountId в первый раз.

Это то, что я реализовал для HTTP Verb POST: 

POST /api/v1/sites/:siteId/accounts/:accountId/apps

params: {
  siteId: string,
  accountId: string,
},
body: {
  provider: '[** Provider **]',
  description: '[** Description **]',

  siteId: '[** Site ID **]',
  accountId: '[** Account ID **]'
},
response: new `appId`

Или это должно быть (к чему я начинаю склоняться): 

POST /api/v1/apps

body: {
  provider: '[** Provider **]',
  description: '[** Description **]',

  siteId: '[** Site ID **]',
  accountId: '[** Account ID **]'
},
response: new `appId`

Рекомендации действительно приветствуются!

1 Ответ

0 голосов
/ 15 января 2019

Во-первых, было бы немного странно иметь siteId и accountId как в url, так и в теле. URL-адрес предполагает, что вы создаете приложение для определенного сайта, а затем сайт является переменной в теле сообщения, то есть это может быть любой сайт. Это только приведет к путанице.

Хотите ли вы, чтобы кто-то мог зарегистрировать новое приложение для любой комбинации сайта / аккаунта? Или кто-то может перейти от выбора сайта к регистрации нового приложения для этого сайта. В первом случае я бы поставил все это в теле, во втором - перейти с сайта в URL.

Учитывая RESTfulness; Когда вы используете API для поиска сайтов или определенного сайта, прежде чем зарегистрировать приложение на определенном сайте, объект 'site' в ответе будет содержать ссылку на то, где можно зарегистрировать приложение для этого сайта. Эта ссылка, вероятно, будет содержать идентификатор сайта. Однако, если бы это был просто URL, где вы могли бы зарегистрировать любой сайт, siteId не имел бы места в URL и даже не был бы частью этого конкретного ответа.

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

...