УСПОКОИТЕЛЬНЫЙ вопрос об архитектуре услуг

Полезно подумать о том, как вы хотите, чтобы клиенты получали данные. Если вы хотите, чтобы клиент собрал целую кучу информации о многих фотографиях, то список только из может быть неоптимальным, поскольку клиент будет затем они будут вынуждены выполнять запрос 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, вы вернете все под , а также все дочерние элементы каждого .

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 немного проще.

На самом деле нет правильного или неправильного ответа на вопрос «как мне разрабатывать свои типы мультимедиа». Однако есть несколько очень важных рекомендаций при выборе существующих и разработке новых типов мультимедиа.

Системы RESTful достигают масштабируемости за счет тщательного использования кэширования . Создание ресурсов для разбиения контента на фрагменты со схожей изменчивостью данных. Например, в вашем сценарии у вас есть список галерей, содержащих фотографии. Я предполагаю, что вы не очень часто добавляете / удаляете галереи, но вы добавляете / удаляете фотографии регулярно. Поэтому имеет смысл убедиться, что вы можете получить список галерей, в которых нет информации о фотографиях. Это упростило бы кеширование этого ответа.

Оптимизация размера ответов может быть важна для производительности, но кэширование гораздо важнее . Отправка 0 байтов по сети всегда более эффективна.

Несмотря на то, что список фотографий может меняться более регулярно, вы все равно можете эффективно использовать кеширование. Используя заголовок if-modified-Since или etags , вы не сохраните сеть и обратно, но вы можете значительно сэкономить полосу пропускания, не передавая представления, которые не изменились.

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

В создании нет ничего плохого:

/gallery/foo/quickview
/gallery/foo/detailedview
/gallery/foo/justlinks

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

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

Большинство людей, когда они начинают использовать сервисы REST, привыкают к мысли, что они могут доставлять в качестве медиа-типа прямые application / xml или application / json. В некоторых особых случаях это вполне выполнимо, однако, когда вы начнете реализовывать больше ограничений REST, вы обнаружите, что эти универсальные форматы типов мультимедиа ограничивают преимущества, которые вы можете получить во многих случаях . На данный момент не особо беспокойтесь об этом, просто имейте в виду, что всегда безопаснее выбрать «настоящий» тип носителя, например application / xhtml, RDF или Atom, и если вы выберете application / xml, вы можете столкнуться с трудностями. позже.

Вы всегда можете использовать атрибуты.

  <gallery id = "1" name = "Gallery 1">
      <photos>
          <photo id="1" link="http://mysite/photo/11111" />
          <photo id="2" link="http://mysite/photo/22222" />
          <photo id="3" link="http://mysite/photo/33333" />
      </photos>
  </gallery>

Или вы можете использовать JSON. Я предпочитаю его, так как он проще и легче, чем XML.

{
    "gallery": {
        "id": "1",
        "name": "Gallery 1",
        "photos": [
            {
                "id": "1",
                "link": "http://mysite/photo/11111" 
            },
            {
                "photo": "2",
                "link": "http://mysite/photo/22222" 
            },
            {
                "photo": "3",
                "link": "http://mysite/photo/33333" 
            } 
        ] 
    } 

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

Я предлагаю вам не теряться на "перекрестке выбора". Просто выберите одну реализацию, основанную на том, что вы предполагаете об использовании клиента. Посмотрите, как все это будет использоваться и вести себя, а затем доработайте, если потребуется. Промойте. Прополощите. Повторяйте. Делайте это постоянным бета-способом :)