Почему идентификация ресурсов так важна для интерфейса веб-сервисов RESTful? - PullRequest
5 голосов
/ 28 января 2011

Я читаю RESTful Web Services Cookbook и есть полная глава об идентификации ресурсов. Автор подчеркивает важность процесса идентификации. Почему это так важно?

РЕДАКТИРОВАТЬ: " API REST должны быть гипертекстовые " Роя Филдинга довольно интересно. Я должен признаться, что не до конца понимаю, о чем на самом деле говорит Рой Филдинг - из-за моего невежества, конечно, - но, похоже, это относится к моим вопросам.

Ответы [ 2 ]

2 голосов
/ 28 января 2011

Поля не имеет особого значения при выборе идентификаторов.

5.1.5 Универсальный интерфейс

Центральная особенность, которая отличает архитектурный стиль RESTИз других сетевых стилей делается акцент на единый интерфейс между компонентами .[...] REST определяется четырьмя интерфейсными ограничениями: идентификация ресурсов [emph.добавлено];манипулирование ресурсами через представления;информативные сообщения;и гипермедиа как движок состояния приложения.

5.2.1.1 Ресурсы и идентификаторы ресурса

REST использует идентификатор ресурса для идентификации конкретного ресурса, участвующего во взаимодействии междукомпоненты.[...] Орган именования, назначивший идентификатор ресурса, позволяющий ссылаться на ресурс, отвечает за поддержание семантической достоверности отображения во времени (т. Е. За то, что функция членства не изменяется).

Традиционные гипертекстовые системы, которые обычно работают в закрытой или локальной среде, используют уникальные идентификаторы узлов или документов, которые меняются каждый раз при изменении информации, полагаясь на серверы ссылок, чтобы поддерживать ссылки отдельно от контента.Поскольку централизованные серверы ссылок - это анафема для огромного масштаба и многопрофильных требований к домену в Интернете, вместо этого REST полагается на автора, выбирающего идентификатор ресурса, который наилучшим образом соответствует природе идентифицируемой концепции.Естественно, качество идентификатора часто пропорционально сумме денег, потраченной на сохранение его действительности, что приводит к неработающим ссылкам, когда эфемерная (или плохо поддерживаемая) информация перемещается или исчезает со временем.

Этокажется, что он соответствует основному пункту « Прохладные URI не меняются », что, хотя конкретное соединение идентификатора и ресурса может измениться, сам идентификатор всегда должен существовать после его создания.Другой момент Филдинга в отношении идентификаторов заключается в том, что они должны представлять единый интерфейс.HTTP-URL достигают этого частично благодаря своей иерархической природе (по крайней мере, они должны быть иерархическими).Однако URI в целом не должны быть иерархическими.

Единый интерфейс и иерархические идентификаторы могут упростить одну из основных функций сервера: сопоставление идентификаторов с ресурсами.Проще говоря, представления хранятся в той же иерархии, что и идентификаторы, когда выполняемое сопоставление заключается в добавлении корня документа к URI запроса, хотя веб-службы редко используют простое сопоставление.

Книга, которую вы читаете, предлагаетего собственная причина посвятить главу выбору идентификаторов:

Из всех аспектов разработки веб-службы RESTful, таких как идентификация ресурсов, выбор типов и форматов мультимедиа и применение унифицированного интерфейсаидентификация ресурса - самая гибкая часть.

Чем больше вариантов, тем больше работы.Если бы идентификаторы были жесткими и предлагали мало вариантов, вам было бы не о чем думать.Кроме того, поскольку URI так заметны, и вам придется долгое время жить со своими вариантами, вам лучше подумать над ними.

1 голос
/ 28 января 2011

Я думаю, что отчасти это объясняется тем, что это противоречит многим современным проектам распределенных приложений.Поскольку в REST ваш интерфейс (глаголы) четко определены (HTTP-глаголы, если это то, о чем мы говорим), остается работа по идентификации ресурсов.

Идентификация ресурсов (URI) также влияет на кэширование- если вы заинтересованы в кэшировании, вы захотите разбить ресурсы таким образом, чтобы вы могли кэшировать повторно используемые, редко изменяемые ресурсы.

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

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