Заголовки ссылок на элементы ссылок для RESTful JSON

При создании API RESTful/hypermedia с ресурсами JSON, похоже, у меня есть два варианта для определения связей гиперссылки между ресурсами.

  • Вставить ссылки в тело документа JSON. Проблема здесь в том, что для указания гиперссылок нет стандартизованного синтаксиса, хотя я вижу ряд хороших усилий: (HAL, Collection + JSON, JSON-LD, JSON Schema, чтобы назвать несколько).

  • Используйте заголовки HTTP-ссылок. Это стандартизировано, поэтому это, по-видимому, имеет преимущество перед встроенными ссылками. Клиенты просто понимают, как понимать стандартный заголовок и вуаля, достигается гипермедиа.

Итак, в частности, в контексте обработки ресурсов JSON, каков путь и почему?

Ответы

Ответ 1

Перейдите в формате гиперссылки JSON. Хотя заголовки каналов являются стандартными, они плохо приняты. Они действительно более подходят для медиаформатов, которые не являются гипермедиа. Но поскольку у вас есть выбор и вы можете выбрать формат гипермедиа (в отличие от, скажем, PNG против JPG), вы должны просто выбрать один и двигаться вперед.

Все стандарты JSON раздуваются, пока тот или иной не станет стандартом "де-факто". Чем больше они используются, тем больше "де-факто" они получают.

Мне кажется, что HAL находится на сплошном стандартном треке, и я бы выбрал это.

Но в любом случае, перейдите в формат гипермедиа, потому что вы можете.

Ответ 2

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

http://tools.ietf.org/html/draft-nottingham-linked-cache-inv-01

Если вы просто хотите разоблачить ссылки на своих клиентов, вам лучше помещать их в объект, чтобы использовать ссылки внутри вложенных элементов:

{
    'item': [
        { 'name': 'fork',  'href': 'http://example.com/item/1' },
        { 'name': 'spoon', 'href': 'http://example.com/item/2' },
        { 'name': 'spork', 'href': 'http://example.com/item/3' }
    ],
    'href': 'http://example.com/items'
}

Ответ 3

  • Связи заголовков могут рассматриваться посредниками.
  • Заголовки каналов сжаты SPDY
  • Стандартные заголовки каналов

Они могут даже содержать JSON, если это необходимо! http://tools.ietf.org/html/draft-nottingham-link-hint-00

Этот подход позволяет выполнять доставку в одно и то же время во всех ответах:

  • Заголовки ссылок, содержащие информацию гипермедиа
  • полезная нагрузка, предназначенная для представления ресурсов

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

Что делает это решение окончательно привлекательным, это IMHO подсказка "accept-post".

Ответ 4

Вы не можете сжимать заголовки. Если у вас много ссылок. Это может иметь значение.

Предоставление контекста для ссылки. Заголовки ссылок имеют атрибут привязки, но нет стандартизованного синтаксиса пути YMMV.

С головы до ног я не могу думать ни о каких других плюсах и минусах.

Ответ 5

Мне кажется, что я использую обе альтернативы (заголовки ссылок и гипермедиа-ссылки в теле ответа после стандартного формата, такие как HAL) позволяют вашему решению воспользоваться преимуществами обоих подходов. Конечно, это звучит неплохо, если ваша среда разработки REST поддерживает автоматическое создание ссылок в обоих местах.