Хорошая вещь, которую стоит рассмотреть, - это то, как вы собираетесь получать данные от клиентов.Если вы хотите, чтобы клиент получил целую кучу информации о многих фотографиях, тогда список только <photo href="..."/> может оказаться неоптимальным, поскольку клиент будет вынужден выполнить запрос GET для каждого ресурса фотографии, который ему нужен.информация о.
Я могу придумать пару интересных способов обойти это без предела.
Вы можете позволить клиенту указать поля, которые он хотел бы получить, в качестве параметров запроса.при запросе списка, например:
GET http://www.example.com/photos?_fields=author,fileSize
Это может затем вернуть что-то вроде:
<photos href="/photos?_fields=author,fileSize">
<photo href="/photos/15">
<author href="/authors/2245"/>
<fileSize>32MB</fileSize>
</photo>
...
</photos>
В качестве альтернативы, вы можете упростить его, позволив клиенту указать какой-то максимум "свойство глубины;это немного более грубо, но может быть эффективно использовано.Например, если клиент указал глубину 2, вы бы вернули все под <gallery>, а также все дочерние элементы каждого <photo>.
GET /galleries?depth=2
Может вернуть что-то вроде:
<galleries>
<id>22</id>
<name>My Gallery</name>
<!-- full gallery data -->
<photos href="/photos?gallery=/galleries/22">
<photo href="/photos/99">
<id>99</id>
<author href="/authors/4381"/><!-- href instead of including nested author data -->
<fileSize>24MB</fileSize>
<!-- full photo data -->
</photo>
...
</photos>
</galleries>
Помимо этого, если вы беспокоитесь о клиенте, запрашивающем много-много записей одновременно (например, если есть тысячи фотографий или галерей), вы можете подумать о некоторой подкачке ваших списков.,Это может включать установление жесткого максимума для результатов в вашем коде и предоставление клиенту ссылок на следующие / предыдущие страницы:
GET /photos?gallery=/galleries/59
Возможно возвращение:
<photos href="/photos?gallery=/galleries/59&_max=100&_first=100" next="/photos?gallery=/galleries/59&_max=100&_first=200" prev="/photos?gallery=/galleries/59&_max=100&_first=0" count="100" total="3528">
....
</photos>
Клиенты могут контролировать _first и _max свойств, но никогда не сможет увеличить _max сверх определенного настроенного порога.Вы вернете количество «найденных» результатов для страницы в разметке, а также общее количество доступных результатов.Это поможет вам сократить размеры ответов, о которых вы упомянули.Это можно сделать параллельно с перечисленными выше опциями.
В конечном итоге все зависит от того, как вы хотите, чтобы ваш сервер давал указание клиентам получать данные.Если вы не хотите, чтобы они делали GET для каждой фотографии, возможно, вы захотите предоставить им более удобные способы получения более глубоких данных.Но если вы считаете, что ваш сервер может справиться с приличной нагрузкой, и наряду с этим вы можете выполнить оптимизацию на стороне сервера (кэширование, использование 304 состояний и т. Д.), То просто вернуть поверхностные списки с href s немного проще.