Сложные / составные / вложенные ресурсы REST [закрыто]
Я пытаюсь обдумать, как лучше всего использовать концепции в API на основе REST. Плоские ресурсы, не содержащие других ресурсов, не проблема. Проблемы возникают со сложными ресурсами.
Например, у меня есть ресурс для комиксов. Комикс имеет всевозможные свойства, такие как автор , номер выпуска , дата и т. Д.
В комиксе также есть список обложек 1..n . Эти обложки представляют собой сложные объекты. В них содержится много информации о обложке: исполнитель, дата и даже изображение обложки в кодировке base 64.
Для GET на ComicBook я мог бы просто вернуть комикс и все обложки, включая их изображения с base64'ed. Это, наверное, не имеет большого значения для одного комикса. Но предположим, что я создаю клиентское приложение, которое хочет перечислить все комиксы в системе в таблице.
Таблица будет содержать несколько свойств из ресурса ComicBook , но мы определенно не захотим отображать все обложки в таблице. Возврат 1000 комиксов, каждая с несколькими обложками, приведет к смехотворно большому количеству данных, передаваемых по сети, данных, которые в этом случае не нужны конечному пользователю.
Мой инстинкт - сделать Обложку ресурсом, а Комикс содержать обложки. Итак, теперь Cover - это URI. GET для комиксов теперь работает, вместо огромного ресурса Cover мы отправляем обратно URI для каждой обложки, и клиенты могут получать ресурсы обложки по мере необходимости.
Теперь я есть проблема с созданием новых комиксов. Конечно, я захочу создать хотя бы одну обложку при создании комикса , на самом деле это, вероятно, бизнес-правило.
Так что теперь я застрял, я либо заставляю клиентов применять бизнес-правила, сначала отправляя обложку , получая URI для этой обложки, а затем POST в ComicBook с этим URI в списке, или мой POST на ComicBook принимает другой вид ресурса, чем он выплевывает. Входящие ресурсы для POST и GET являются глубокими копиями, где исходящие GET содержат ссылки на зависимые ресурсы.
Ресурс Обложка , вероятно, понадобится в любом случае, потому что я уверен, как клиент, в некоторых случаях хотел бы обратиться к направлению прикрытия. Таким образом, проблема существует в общем виде независимо от размера зависимого ресурса. В общем, как вы обрабатываете сложные ресурсы, не заставляя клиента просто «знать», как эти ресурсы состоят?