Как вы избегаете фиксированного ресурса

Question

Рой Филдинг пишет

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

Как вы делаете это для межсистемных интерфейсов? Скажем, клиент хочет создать заказ на сервере по номеру http://my.server.org Как узнать, что для создания заказа следует использовать URL http://my.server.org/newOrder, а не http://my.server.org/nO или что-нибудь еще?

Для человеческого интерфейса (т. Е. Браузера), я думаю, сервер предоставит какую-либо форму ссылки (возможно, в элементе form), а текст вокруг и в этой ссылке скажет пользователю, какая из форм на этой странице является правильным для создания заказа (как предполагается для создания пользователя или перехода к какому-либо результату поиска)

Какие механизмы используются для реализации этого на стороне клиента? А также: они действительно используются или большинство людей просто внедряют URL-адреса в клиента?

Answer 1

Как ты это делаешь для межсистемные интерфейсы? Скажи клиент хочет создать заказ в сервер на http://my.server.org Как это он должен был узнать, что для создания заказ должен использовать URL http://my.server.org/newOrder и нет http://my.server.org/nO или что-нибудь еще

Это не учится. Машинные клиенты, как правило, не могут «учиться». По крайней мере, пока, мы все еще пре-Скайнет. Вы должны "учить" их.

Но главное в том, что вы не учите их URL-адресам. Вы учите их отношениям.

Рассмотрим в HTML ...

<a rel="order" href="http://my.server.org/newOrder"/>

и

<a rel="order" href="http://my.server.org/nO"/>

Вы заметите, что rel - это то же самое, "order", но URL - нет.

В «идеальном» мире ваша система будет иметь единую точку входа, скажем, http://my.server.org/, и оттуда клиент сможет найти все необходимые им сведения.

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

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

В документации вашего гипермедиа API объясняется, как применять унифицированный интерфейс к каждой из версий, с которыми столкнется ваш клиент. Клиент также не может «интуитивно» это понять, этому нужно учить.

По сути, обучая клиента тому, как ориентироваться в отношениях, которые он будет или МОЖЕТ найти в полезных нагрузках, которые он обрабатывает, клиент манипулирует гипермедиа API. Полезные данные содержат подписанные сообщения, чтобы показать путь, но сервер определяет, куда отправляются эти подписывающие сообщения.

Что касается того, как часто оно используется, в мире машин и машин, скорее всего, не очень. Большинство систем недостаточно велики, когда URL-адреса меняются настолько, чтобы иметь значение, а клиентов так мало, что смена клиентов не является существенным бременем. Так что большинство просто жесткий код прочь.

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

Answer 2

Независимо от того, как вы публикуете API (для использования на машинах), можно вносить критические изменения.

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

Несколько способов избежать взлома машинных клиентов (в основном, поддержка обратной совместимости):

• Создайте какое-то управление версиями URL
• Перенаправление со старых схем URL на новую схему

Answer 3

Мы довольно успешно подошли к нему следующим образом: выставить файл WADL по самому корневому URL-адресу приложения, описывающего типы мультимедиа , а также где найти ссылки в нем и их семантику . Я знаю, что это (WADL) является чем-то критически важным в REST-сообществе, но я всегда чувствовал себя испуганным только из-за того, что WADL фокусируется только на URL. Помимо религиозных дебатов нам нравилось иметь четко определенный способ документирования представлений. Существует способ обойти фокус WADL по URL и, скорее, указать, где можно найти ссылки в представлении, а затем задокументировать это. См. в этом блоге (в настоящее время он недоступен из-за технического обслуживания, поэтому вы можете посмотреть его в Google cache ), чтобы узнать подробнее о подходе.

Это приводит к тому, что клиенту будет известен только один URL-адрес, поскольку он может узнать о его доступе к WADL, а затем просто узнать о представлении и где найти ссылки, какому методу HTTP нужны какие параметры при работе вызывается и т. д.