Как вы представляете "тонкую" и "толстую" версии ресурса RESTful?

Question

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

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

Как можно моделировать это?

Я вижу несколько вариантов:

1. эти два представления на самом деле два разных ресурса и требуют разных URI
2. эти два представления фактически являются одним и тем же ресурсом, и вы можете выбирать между двумя представлениями с помощью пользовательских типов мультимедиа, например application/vnd.movie.thin+json а также application/vnd.movie.fat+json,
3. эти два представления фактически являются одним и тем же ресурсом, и выбор разных представлений должен выполняться с помощью параметров запроса (например, /movies/1?view=thin).
4. Что-то другое...

Что вы считаете правильным подходом к такого рода API?

Answer 1

Вы можете использовать предпочтительный заголовок с параметром return-minimal.

Answer 2

Я предпочитаю использовать Content-Type для этого. Вы также можете использовать параметры:

application/vnd.myapp; profile=light

Answer 3

В диссертации Fielding о REST рассказывается об интерфейсе ресурсов, о том, что вы должны связать свои IRI с ресурсами, которые являются наборами сущностей. (Это отличается от SOAP, потому что там вы обычно связываете свои IRI с операциями.)

Согласно Darrel Miller, путь предназначен для описания иерархических данных, а строка запроса - для описания неиерархических данных в IRI, но мы используем путь и запрос вместе, чтобы идентифицировать ресурс внутри API.

Таким образом, на основе этих у вас есть два подхода:

• Можно сказать, что тот же объект с меньшим количеством свойств может быть сопоставлен с новым ресурсом с собственным IRI. В этом случае /movies/1?view=thin или /movies/1/view:thin хорошо.
  Плюсы:

  • Согласно RDF собственность имеет rdf:type из rdf:Property а также rdfs:Resource либо REST имеет связи с семантической сетью и связанными данными.
  • Обычной практикой является создание IRI для одного свойства, например /movies/1/title, так что если мы можем сделать это с помощью одного свойства, то мы можем сделать это и с помощью набора свойств.
  • Это похоже на сокращение карты, которое мы уже используем для сбора объектов: /movies/recentи т. д. Единственное отличие состоит в том, что с помощью набора сущностей мы уменьшаем список или упорядоченный набор, а с помощью набора свойств мы уменьшаем карту. Гораздо интереснее использовать оба в комбинации, например: /movies/recent/title, который может вернуть названия последних фильмов.

  Минусы:

  • По RDF все имеет rdf:type из rdfs:Resource и, возможно, REST не следует тем же принципам в веб-документах.
  • Я не нашел ничего об отдельных свойствах или коллекциях свойств, которые могут или не могут рассматриваться как ресурсы в диссертации, однако я могу случайно пропустить этот раздел текста (довольно сухой материал)...

• Вы можете сказать, что один и тот же объект с меньшим количеством свойств - это просто другое представление одного и того же ресурса, поэтому у него не должно быть другого IRI. В этом случае вы должны поместить свои данные о предпочтительном представлении в другое место в запросе. Поскольку в GET-запросах тела нет, а HTTP-метод не предназначен для хранения подобных вещей, единственное место, куда вы можете поместить его, - это HTTP-заголовки. При длительных пользовательских настройках вы можете сохранить их на сервере или в файлах cookie, поддерживаемых клиентом. По краткосрочным настройкам вы можете отправить его во многих заголовках. Посредством content-type В заголовке вы можете определить свой собственный тип MIME, который не рекомендуется, потому что нам не нравится, когда сотни пользовательских типов MIME, вероятно, используются только одним приложением. Посредством content-type В заголовке вы можете добавить профиль к вашему типу MIME, как предложил Doug Moscrop. По prefer Заголовок вы можете использовать return-minimal настройки, как предложил Darrel Miller. От range Заголовки вы можете сделать то же самое в теории, но я встречал заголовки диапазона только путем разбивки на страницы.
  Плюсы:

  • Это, безусловно, подход RESTful.

  Минусы:

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

примечание: лично я предпочитаю использовать первый подход, но это всего лишь мнение.

По словам Darrel Miller, наименование IRI на самом деле не считается REST.

Вам просто нужно убедиться, что один IRI всегда указывает на один и тот же ресурс, и это все. Структура IRI не учитывается на стороне клиента, потому что ваш клиент должен соответствовать ограничению HATEOAS, если вы не хотите, чтобы он нарушался при любых изменениях именования IRI. Это означает, что сервер всегда создает IRI, а клиент следует этим IRI, которые он получает в ответе гипермедиа. Это похоже на использование веб-браузеров для перехода по ссылке и просмотра веб-страниц... С помощью REST вы можете добавить некоторую семантику в вашу гипермедиа, которая объясняет вашему клиенту, что он просто получает. Это может быть некоторый словарь RDF, например schema.org, микроданные, отношения ссылок iana и т. Д. (Даже ваш собственный словарь для конкретного приложения)...
Таким образом, использование хороших IRI не является проблемой для REST, а только для настройки маршрутизации на стороне сервера. Что вы должны убедиться в REST IRI, что у вас есть ресурс - сопоставление IRI, а не операция - сопоставление IRI, и вы не используете IRI для поддержания состояния клиента, например, для хранения идентификатора пользователя, учетных данных и т. Д.