Как отправить глубоко вложенные ресурсы с помощью Restful APIs (HATEOAS)

Question

Скажите, что у меня есть ресурс приложения, содержащий ресурсы контактной информации, а контактные данные содержат ресурсы адресов.

Например.

Application 
--> Name 
--> Application Amount 
--> Application Contacts 
--> --> Contact 1 
--> --> --> Address 
--> --> Contact 2 
--> --> --> Address 

При выполнении POST для приложения я создаю корневое приложение. Для всех вспомогательных ресурсов, таких как Application Contacts, я делаю POST для создания контакта 1 и т. Д.

Мой вопрос: приложение = отправить что-то для обработки, но я не хочу его отправлять, прежде чем все будет заполнено , ака всех детей.

So the order of submission 
1) Create Application Resource --> POST /Application --> Get ID 
2) Create Contact 1 Resource --> POST /Application/id/Contacts --> Get ID 
3) Create Contact 1 Address Resource --> POST /Application/id/Contacts/id/Addresses 
4) Create Contact 2 Resource --> POST /Application/id/Contacts --> Get ID 
5) Create Contact 2 Address Resource --> POST /Application/id/Contacts/id/Addresses 
6) DECIDE TO SUBMIT HERE <--- ?? HOW? 

Джош

Answer 1

Ваш дизайн не RESTful. Ваши ресурсы, вероятно, являются сопоставлениями 1 к 1 с вашими бизнес-единицами? Я не советую этого, потому что он разоблачает кишки вашей модели домена во внешнем мире, что может вызвать проблемы с версиями. Это также делает такие проблемы сложнее, чем они должны быть - хотя вы можете использовать структуру REST, которая заставляет этот дизайн на вас :-(

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

Решение здесь, я бы сказал, чтобы POST создавал Приложение , также создает Контакты и их Адреса. Затем клиент может либо указывать URL-адреса для существующих Контактов и Адресов (которые сервер может разыменовать для объектов домена), либо необходимый детали для создания новых в одном POST. Тогда ответственность за создание и связывание объектов транзакционным способом зависит от сервера. Он просто возвращает ссылку на URL-адрес, который идентифицирует новое приложение. Если вам нужно знать URL-адреса для контактов, то вы повторно установите приложение, и оно будет содержать их.

Предполагая JSON тип пантомимы для вашего ресурса, первоначальный POST может выглядеть следующим образом:

{ 
    Name: "Application name", 
    Amount: "123.00", 
    Contacts: [ 
     { 
      Name: "Contact name", 
      Address: { 
       HouseNumber: "45", 
       StreetName : "Sesame Street" 
      } 
     } 
    ] 
} 
Return: {href: “/Application/6789”} 

GET в/Application/6789 затем вернуть что-то вроде:

{ 
    Name: "Application name", 
    Amount: "123.00", 
    Contacts: [ 
     { mimeType: "application/vnd.com.myStuff.contact+json", href: "/Contact/203" } 
    ] 
} 

Answer 2

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

Итак, если все «подресурсы» уже созданы с шага-1 до шага-5. На каждом шаге должен быть возвращенный идентификатор, чтобы подтвердить успешное создание ресурса. Например,

POST /Application 
Return: {appid: “/Application/id”} 

Таким образом, как только POST-шаг 5, создается последний ресурс. Затем следующим шагом будет запуск «обработки» приложения.

«Обработка заявок» может рассматриваться как ресурс, и бизнес-действия: «создать обрабатываемую» ресурс и «Проверка результатов обработки»

Они могут быть смоделированы с помощью POST и GET соответственно на " Обработка ".

Для создания ресурса обработки

POST /Application/id/Processing 
Return: {processingid: “/Application/id/Processing/id”} 

Для проверки ресурса,

GET /Application/id/Processing/id 
Return: {processingid: “/Application/id/Processing/id”, <other info>} 

обработка Чтобы получить все приложение обратно,

GET /Application/id 
Return: {all info on the application including processing status as well…} 

Надежда эта помощь.

Answer 3

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

1) Пост в качестве ресурса приложения с его полем состояния, установленным в нужное значение, чтобы указать свое намерение:

POST /application/654321 
status=submitted... 

Вот цитата из Fielding Dissertation:

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

2) Дать заявку на определенную коллекцию/submittedapplications, которые вы можете использовать для поиска ваших представленных приложений через GET:

POST /submittedapplications 
id=654321... 

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

BTW оба подхода не являются взаимоисключающими, можно, конечно, реализовать и в том же API.