Как решить две проблемы REST: интерфейсный документ;потеря конфиденциальности в описательных URL

Question

Исходя из многих неприятных моментов с WSDL / Soap, мне очень нравится парадигма REST, но я пытаюсь решить две основные проблемы в нашем приложении, прежде чем перейти к REST.Первая проблема связана с отсутствием документа интерфейса.Я думаю, что наконец-то вижу, как справиться с этой ситуацией: можно запросить его путь вниз от ресурса "/ resources" верхнего уровня, используя различные запросы GET, HEAD и OPTIONS, чтобы найти нужный ресурс в правильном формате гипермедиа.Это идея?Если это так, клиенту нужно предоставить только URI ресурса верхнего уровня: http://www.mywebservicesite.com/mywebservice/resources. Затем ему придется выполнить поиск и, возможно, отследить то, что он обнаруживает, чтобы он снова мог эффективно использовать URI.в будущем делать GET, POST, PUT и DELETE.Есть какие-нибудь мысли о том, что здесь должно произойти?

Другая проблема заключается в том, что мы не можем использовать описательные URL-адреса, такие как /resources/../customer/Madonna/phonenumber.У нас есть реализация непрозрачных URL, которые мы используем в контексте сеанса, и мне интересно, как непрозрачные URL могут быть применены к REST.Общая проблема заключается в том, как сохранить детализацию, относящуюся к домену, из URL-адресов и при этом использовать преимущества REST.

Answer 1

Другая проблема заключается в том, что мы не можем использовать описательные URL-адреса, такие как /resources/../customer/Madonna/phonenumber.

Я думаю, вы неправильно поняли суть непрозрачных URI. Понятие непрозрачных URI относится к клиентам: Клиент не должен расшифровывать URI , чтобы угадать что-либо из семантического значения из него. Так что сервис может иметь такие URI, как /resources/.../customer/Madonna/phonenumber, и это неплохая идея. URI должны считаться непрозрачными клиентами: не следует из URI выводить, что он представляет номер телефона Мадонны и что Мадонна является клиентом какого-то рода. Это знание можно получить, только заглянув внутрь самого URI или, возможно, вспомнив, где был обнаружен URI.

Edit:

Следствием этого является то, что навигация должна осуществляться по ссылкам, а не путем деконструкции URI. Поэтому, если вы видите /resouces/customer/Madonna/phonenumber (и на самом деле это номер телефона Заказчика Мадонны), у вас должны быть ссылки на этот ресурс, чтобы указывать на ресурс Мадонны: например,

{
  "phone_number" : "01-234-56", 
  "customer_URI": "/resources/customer/Madonna" 
}

Это единственный способ перейти от ресурса номера телефона к ресурсу клиента. Важным аспектом является то, что реализация сервера может содержать или не содержать информацию, относящуюся к домену, в URI. Запись Мадонны с таким же успехом может существовать где-то еще: /resources/customers/byid/81496237. Вот почему клиенты должны рассматривать URI как непрозрачные.

Редактировать 2:

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

1. Предоставить интерфейс поиска . Это может быть сделано путем предоставления документа описания OpenSearch, в котором говорится, как искать элементы. Шаблон OpenSearch может включать несколько переменных и несколько конечных точек, в зависимости от того, что вы ищете. Поэтому, если у вас есть уникальный идентификатор клиента, вы можете использовать следующий шаблон: /customers/byid/{proprietary:customerid}", элемент customerid должен быть где-то задокументирован, внутри пространства имен proprietary. Затем клиент может знать, как использовать такой шаблон.

2. Предоставьте пользовательскую форму . Это подразумевает создание пользовательского типа мультимедиа, в котором вы явно определяете, как (на основе экземпляра документа) можно подделать URI для клиента. <customers template="/customers/byid/{id}"/>. В документации (для типа носителя) должно быть указано, что атрибут шаблона должен интерпретироваться как относительный URI после замены строки "{id}" на фактический идентификатор клиента.

3. Предоставить ссылки на все ресурсы . Некоторые ресурсы не являются бесчисленными, поэтому вы можете просто сделать ссылку на каждый из них, опционально включая идентификационную информацию вместе со ссылками. Это также может быть сделано в пользовательском типе носителя: <customer id="12345" href="/customer/byid/12345"/>.

Следует отметить, что # 1 и # 2 - это два способа сказать одно и то же: клиентам разрешено создавать URI, если они

1. априори не имеет структуры URI
2. существует тип носителя, для которого в документации указано, что должны быть созданы URI

Это почти так же, как веб-браузер не имеет представления о какой-либо структуре URI в Интернете, за исключением правил, изложенных в определении форм HTML, для добавления ?, а затем всех параметров запроса, разделенных &.

Теоретически, если у вас есть клиент с идентификатором 12345, тогда вы можете обойтись без href, поскольку вы можете подключить идентификатор клиента 12345 к # 1 или # 2. Чаще встречается предоставление реальных связей между ресурсами, а не использование методов поиска или поиска.

Answer 2

В настоящее время я создаю REST-агент, который решает первую часть вашего вопроса.Агент предлагает временную услугу закладки.Код клиента, который взаимодействует с агентом, может запросить закладку URL-адреса с использованием некоторого идентификатора.Если клиентскому коду необходимо снова получить это представление, он просто запрашивает у агента URL-адрес, соответствующий сохраненной закладке, а затем переходит к этой закладке.В настоящее время эти закладки не сохраняются, поэтому они сохраняются только на протяжении всего жизненного цикла клиентского приложения, но я нашел это полезным механизмом для доступа к часто используемым ресурсам.Например, корневое представление предоставляет ссылку для входа.Я добавляю эту ссылку в закладки, и если клиент когда-либо получает 401, я могу перенаправить на закладку «логин».

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

Answer 3

На самом деле я не использовал веб-RPC-системы (WSDL / Soap), но я думаю, что «интерфейсный документ» предназначен главным образом для того, чтобы клиентские библиотеки могли создавать сервисный API, верно? если это так, то REST не должен в этом нуждаться, потому что глаголы уже определены и больше не нуждаются в документировании.

AFAIUI, способ REST заключается в документировании структуры каждого ресурса (обычно кодируется в формате XML или JSON). В этом документе вам также придется документировать отношения между этими ресурсами. В моем случае ресурс часто является контейнером других ресурсов (иногда более одного типа), поэтому структура документа определяет, какое поле содержит список URL-адресов, указывающих на содержащиеся ресурсы. В идеале только одному уникальному ресурсу потребуется один фиксированный (задокументированный) URL-адрес. отсюда следует все остальное.

URL-адрес «style» не имеет смысла для клиента, поскольку он не должен «создавать» URL-адрес. Каждый URL, который ему нужен, должен быть уже создан в поле ресурса. Это позволяет вам изменять структуру URL без изменения клиента (это сэкономило мне кучу времени). Ваши URL-адреса могут быть непрозрачными или описательными, как вам нравится. (лично мне не нравятся текстовые ключи или слизни; все мои ключи - BIGINT или UUID)