Подтвердить что ты не робот

Действия REST и соображения API API

Я создаю систему управления запасами, и я занят проектированием (мышлением) API и моей реализацией REST.

У меня есть следующие ресурсы, и на ресурсе вы можете выполнять много действий/операций. Каждая операция изменяет ресурс, а в некоторых случаях создает новый ресурс, а также создает историю или транзакции.

Я ищу информацию от экспертов относительно удобства использования и приемлемости в отношении дизайна URL и ресурсов. Приветствия и примеры реального мира, любое мнение или критика приветствуются.

Мои опасения в том, что все приложение может развиваться вокруг этого одного большого ресурса? Мой внутренний стек будет С# и servicestack framework, и для интерфейса я буду использовать HTML и AngularJS. Не то чтобы это имело значение.

Сценарий 1. Типичная операция:

POST /inventory/{id}/move
POST /inventory/{id}/scrap
PUT  /inventory/{id}/takeon
POST /inventory/{id}/pick
PUT  /inventory/{id}/receive
POST /inventory/{id}/hold
POST /inventory/{id}/release
POST /inventory/{id}/transfer
POST /inventory/{id}/return
POST /inventory/{id}/adjustment


{
  "userID": "",       //who is doing the actions (all)
  "tolocationID": "", //new location for inventory (move/takeon/pick/receive/transfer/return)
  "qty": "",          //qty (pick/receive/takeon/transfer/return)
  "comment": "",      //optional for transaction (all)
  "serial": "",       //(takeon/receive)
  "batch": "",        //(takeon/receive)
  "expirydate": "",   //(takeon/receive)
  "itemCode": "",     //(takeon/receive)
  "documentID": "",   //(pick/receive/return/transfer)
  "reference" :"",    //(all)
  "UOM" :"",          //(all)
  "reference" :"",    //(all)
}

Это приемлемо в отношении стандартов. Другой подход может быть.

Сценарий 2.

POST /inventory/{id}/move
POST /inventory/{id}/scrap
PUT  /inventory/{id}/takeon
POST /document/{id}/pick     //**document**
PUT  /document/{id}/receive  //**document**
POST /inventory/{id}/hold
POST /inventory/{id}/release
POST /document/{id}/transfer  //**document**
POST /document/{id}/return    //**document**
POST /inventory/{id}/adjustment

а затем для изменения ресурсов.

Сценарий 3. На мой взгляд, неправильный

POST /transaction/move/{...}
POST /transaction/scrap/{...}
PUT  /transaction/takeon/{...}
POST /transaction/pick/{...}  
PUT  /transaction/receive/{...} 
POST /transaction/hold/{...}
POST /transaction/release/{...}
POST /transaction/transfer/{...}  
POST /transaction/return/{...}
POST /transaction/adjustment/{...}

Любые комментарии приветствуются, не ищут ответа, но больше советов по соображениям дизайна?

Спасибо, что нашли время, читая эту запись!

4b9b3361

Ответ 1

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

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

GET /inventory/{id}
PUT /inventory/{id} -- update with new location 
PUT /inventory/{id} -- update with new status (scrapped)

и т.д. Это более подход RESTful. Многие из этих действий выглядят так, что они действительно просто PUT, которые обновляют несколько свойств ресурса, таких как местоположение, количество, поле комментариев и т.д. И, возможно, scrap DELETE? Трудно сказать.

Другой вариант - использовать POST, где тело содержит инструкции по работе с элементом инвентаря:

POST /inventory-transactions/{id}
{
    "action": "takeon",
    "newLocationId": 12345,
    ...
}

Это дает вам много прослеживаемости, потому что теперь каждая операция может отслеживаться как ресурс. Слишком большая сторона вокруг конечной точки.

Вы также можете вывести некоторые из операций "глагола" в ресурсы:

POST /returned-inventory
{
    "inventoryId": 12345,
    "documentId": 67890,
    "comment": "Busted up",
    ...
}

Это позволяет вам легко просматривать элементы инвентаря по их статусу, что может быть или не быть полезным. Например, вы можете вызвать GET /returned-inventory?documentId=67890, чтобы вернуть все возвращенные элементы из того же документа.

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

Ответ 2

"Restful Objects", который определяет RESTful API, указывает, что действия действительны.

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

Действия "вызывается" с использованием GET (запроса), PUT (idempotent) или POST (non idempotent)

Restful Object Spec (страница C-125)

Ответ 3

Краткий ответ:

Используйте действия в конце URL, чтобы изменить состояние.

Github делает это так, чтобы пометить звезду: PUT/gists/: gist_id/star

Объясняется здесь https://developer.github.com/v3/gists/#star-a-gist

Длинный ответ:

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

Таким образом, действия и операции по своей сути являются не ресурсами, а действиями над ресурсами. Таким образом, они не будут отвечать на "сопоставление ресурса с URI", как REST.

Но вы можете использовать лучшие из REST и все же лучшие из URI, комбинируя оба.

Помните:

Технология должна работать для вас, а не вы для технологии.

Если вы станете технологическим рабом, вы в конечном итоге создадите непригодные приложения или будете использовать уродливые технологии, такие как XML или Java Home и Remote интерфейсы, поэтому вы в конечном итоге будете писать 5 файлов для создания приложения hello world.

ВНИМАНИЕ от "синдрома блестящего объекта". Погугли это.

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

Возьмите то, что вам нужно от технологии, а затем заставьте технологию работать на вас.

Использование REST api не означает, что вам нужно отказаться от возможностей технологий URL и URI.

Ссылки: https://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api#restful