REST API, имеющий тот же объект, но легкий - PullRequest
9 голосов
/ 21 октября 2011

Мы создаем REST API и хотим вернуть тот же объект, но один вызов - это «облегченная» версия (без всех полей)

Какая лучшая практика?

1-й случай

2-й случай

3-й случай

4-й случай?

Любая ссылка на документированный ресурс REST API приветствуется!

Спасибо.

Ответы [ 2 ]

11 голосов
/ 21 октября 2011

Это должно быть обработано путем согласования контента, вот для чего оно. Согласование контента - это то, как клиент может запросить, какое представление ресурса он хочет увидеть. Рассмотрим случай с изображением: image / x-canon-cr2, image / jpeg, image / png.

Якобы все одно и то же изображение, но в разных форматах.

Итак, это механизм, который вы действительно хотите использовать для «облегченной» версии вашего ресурса. Например, вы можете использовать:

  • «application / xhtml + xml» для основной версии
  • «application / xhtml + xml; lite» для облегченной версии

Итак, для полного ресурса:

GET /resource
Accept: application/xhtml+xml

Для облегченной версии

GET /resource
Accept: application/xhtml+xml; lite

Для любого, но предпочитая облегченную версию:

GET /resource
Accept: application/xhtml+xml;lite, application/xhtml+xml

(более конкретный спецификатор, т. Е. С; lite, имеет больший приоритет над обычным applciation / xhtml + xml.)

Если вы возьмете либо, но предпочитаете полную версию:

GET /resource
Accept: application/xhtml+xml;lite;q=0.1, application/xhtml+xml

Для тех, у кого нет качественного фактора, по умолчанию установлено значение 1,0, поэтому значение 0,1 меньше 1,0, и вы получите полную версию, если она доступна поверх облегченной.

Addenda:

Коэффициент q на Accept эффективно используется для отображения предпочтений клиента. Он используется для определения приоритетности списка типов мультимедиа, которые принимает клиент. Он говорит: «Я могу работать с этими типами носителей, но я предпочитаю, чтобы над и b над с».

JPEG против PNG ничем не отличается от облегченной против полной версии. Тот факт, что JPEG выглядит примерно так же, как и в оригинальном PNG, является оптической иллюзией, данные сильно различаются, и они имеют различное использование. JPEG - это не «низкое качество», это разные данные. Это "пропущенные поля". Если я хочу, скажем, размер изображения, JPEG предоставит мне эту информацию так же, как и PNG. В этом случае его качество соответствует задаче. Если этого не было достаточно, тогда я не должен был бы просить это.

Я могу гарантировать, что если у меня есть клиент, который может обрабатывать только PNG и запрашивать JPEG, то эта программа не будет «работать одинаково хорошо» с ним. Если мой сын хочет Куриные Пальчики, а я дам ему Сливки Шпината, будут проблемы, хотя оба из них - представление ресурса / ужина.

Представление "application / xhtml + xml; lite" - это просто представление, а НЕ сам ресурс. Вот почему используется слово «представление». Все представления являются просто проекциями из фактического ресурса, который представляет собой виртуальную сущность на сервере, реализованную внутри каким-то неопределенным образом.

Некоторые представления являются нормативными, некоторые - нет.

Представления проявляются через типы медиа, а типы медиа обрабатываются через Con-neg и заголовок ACCEPT. Если вы не можете справиться с представлением, не просите об этом.

Это проблема контрагента.

Я не знаю, как «медиаплеер» связан с этим обсуждением.

7 голосов
/ 21 октября 2011

Преимущество 1-го и 3-го случаев состоит в том, что один URL-адрес используется для одного ресурса, а строка запроса используется для запроса конкретного представления этого ресурса. Выбор между ними - дело вкуса, но я предпочитаю по умолчанию получать все данные и сохранять параметры для просмотра подмножеств.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...