RESTfully создание графов объектов

Question

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

Order (основной объект)

• HAS-много адресов
• HAS-много Order Line элементов (то, что делает порядок состоит из)
• Has-многие платежи
• Has-много Контактная информация

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

Есть два варианта проектирования API:

• Порядок API конечных точек разумно создает себя и связанные с ним ресурсы путем обработки «вложенную ресурс» в содержании отправленного в POST /orders
• ресурс заказа только создает себя, и клиент должен сделать последующие запросы POST для вновь созданных конечных точек , например POST /orders/123/addresses, PUT /orders/123/line-items/987, e tc.

Хотя второй вариант проще реализовать на стороне сервера, он заставляет клиента выполнять дополнительную работу в 80% случаев использования.

Первый вариант имеет следующие открытые вопросы:

• Как один URL-адрес общения для вновь созданного ресурса? Заголовок Location может связывать только один URL-адрес, однако сервер потенциально мог бы создать несколько ресурсов.
• Как бороться с ошибками? Что делать, если одна из ассоциаций имеет ошибку? Отбрасываем ли мы весь граф объектов? Как эта ошибка передается клиенту?

Что такое RESTful + прагматичный способ борьбы с этим?

Answer 1

Оба варианта могут быть реализованы RESTful. Вы спрашиваете:

Как сообщить URL-адрес вновь созданного ресурса? Заголовок Location может связывать только один URL-адрес, однако сервер потенциально мог бы создать несколько ресурсов.

Это будет сделано так же, как вы общаетесь links S к другим ресурсам в GET случае. Используйте элементы link или какой ваш метод должен встроить URL-адрес ресурса в представление.

Answer 2

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

В зависимости от вашего варианта использования вы также можете использовать метод «все или ничего» при создании объектов; т.е. если что-то падает, все возвращается. Вы можете сделать это, используя транзакцию в своей базе данных (которую вы также не можете сделать, если все сделано с помощью отдельных запросов). Определение того, какое именно поведение вы хотите, очень специфично для вашей ситуации. Например, если вы создаете заявление о заказе, которое вы можете использовать для этого (вы не хотите создавать ордер, в котором отсутствуют элементы), однако, если вы загружаете фотографии, все может быть хорошо.

Для возврата ссылок на клиент, я всегда возвращаю объект JSON. Вы можете легко заполнить этот объект ссылками на каждый из созданных ресурсов. Таким образом, клиент может определить, как вести себя после успешной публикации.