Дизайн клиента HATEOAS

Question

Я прочитал много обсуждений здесь, на SO, просмотрел Jon Moore's presentation (что объясняло много, кстати) и прочитало сообщение блога Роя Филдинга на HATEOAS, но я все еще чувствую себя немного в неведении, когда дело касается клиента дизайн.

API Вопрос

На данный момент, я просто возвращался с формами XHTML/якорей и списки определений для представления ресурсов. Следующий фрагмент детализирует, как я выкладываю формы/анкеры/списки.

# anchors 
<li class='docs_url/#resourcename'> 
    <a rel='self' href='resource location'></a> 
</li> 

# forms 
<form action='action_url' method='whatever_method' class='???'></form> 

# lists 
<dl class='docs_url/#resourcename'> 
    <dt>property</dt> 
    <dd>value</dd> 
</dl> 

Мой вопрос в основном относится к формам. В разговоре Джона он документирует такие типы, как (add_location_form) и т. Д., И необходимые для них данные. У меня не так много ресурсов, но я думал об абстрактных типах форм (добавлении, удалении, обновлении и т. Д.) И просто запомните в документации, которая для (добавить, обновить), что вы должны отправить действительное представление целевого ресурса и с удалением необходимо отправить идентификатор.

Вопрос 1: С понятием HATEOAS, мы не должны на самом деле просто сделать клиент «открыть» форму (с помощью причислять их добавления, удаления, обновления и т.д.) и просто отправить обратно все данные, дал им? Мой реальный вопрос здесь (не должен быть дискуссией) заключается в том, что это следует за хорошей практикой?

Клиент Вопрос

После HATEOAS, с нашими действиями по ресурсам, которые обнаруживают, в состоянии, как делает этот эффект код клиента (потребители АФИ) и их пользовательский интерфейс. Звучит здорово, что после этих принципов пользовательский интерфейс должен показывать только действия, доступные, но как это реализовано?

Мой текущий подход анализирует ответ как xml и usin xpath для поиска действий, известных во время разработки клиента (задокументированные классы форм, т.е. добавления, удаления, обновления) и отображения элементов управления ui, если они доступный.

Вопрос 2: Я ошибаюсь в своем способе обнаружения? Или это слишком много магии, насколько это касается клиента (зная классы форм)? Разве это не предполагало бы, что клиент знает, какие действия доступны для каждого ресурса (что может быть хорошо, потому что это своего рода причина для создания клиента, правильно?) И должно быть документировано сопоставление действий (классов форм) с ресурсами , или просто документировать классы форм и позволить клиенту (и разработчику клиента) исследовать и обнаруживать их?

Я знаю, что я везде с этим, но любое понимание очень ценится. Я отмечу ответ, отвечающий на любой из этих двух вопросов. Благодаря!

Answer 1

Нет, вы в значительной степени спотыкаетесь.

Браузеры просто визуализируют полезную нагрузку HTML и полагаются на Человека, чтобы на самом деле интерпретировать, находить смысл и потенциально заполнять формы соответствующим образом.

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

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

Потому что это то, что мы делаем, не так ли? Мы видим форму «О, им нужны имя, адрес, номер кредитной карты». Мы знаем не только то, что означает «имя», «адрес» и «кредитная карта», мы также можем понять, что они имеют в виду MY-имя или имя человека на кредитной карте или имя отправленного лица к.

Машины не работают очень хорошо и в «интуитивной» части. Так как разработчик, вы получаете код в логике того, что, по вашему мнению, необходимо для определения правильных фактов и того, как они размещаются.

Но, вернувшись к идеальному клиенту, он увидит каждую форму, «узнает», что хотят поля, проконсультируйтесь со своим внутренним списком «фактов», а затем правильно заполнит полезную нагрузку для запроса и, наконец, сделает запрос.

Вы можете видеть, что тривиальный и явно хрупкий способ сделать это - просто сопоставить имена параметров с внутренними данными. Когда имя параметра является «именем», вы можете записать его так: firstName + «» + lastName. Или вы можете подумать о фактическом отношении «знать», что они говорят о доставке, и использовать: shipTo.firstName + «» + shipTo.lastName.

С течением времени в идеале вы можете создать коллекцию сопоставлений и так, чтобы, если вдруг полезная нагрузка представила новое поле, и это оказалось полем, о котором вы уже знаете, вы можете заполнить это также «автоматически» «без изменений клиенту.

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

Главное, однако, особенно о HATEOS, заключается в том, что вы не «заставляете» свои данные на сервере. Сервер сообщает вам, что он хочет, особенно если они предоставляют вам формы.

Таким образом, процесс размышлений не является «О, если мне нужен счет-фактура доставки, я вижу, что прямо сейчас им нужны имя, адрес и номер заказа, и они хотят, чтобы он был закодирован, и они хотят, чтобы он был отправлен на http://example.com/shipping_invoice поэтому я всегда буду отправлять: имя + «&« + адрес + »&« + orderNumber каждый раз до http://example.com/shipping_invoice. Просто! ».

Скорее то, что вы хотите сделать, это «Я вижу, что они хотят иметь имя, адрес и номер заказа. Так что я сделаю для каждого запроса, я прочитаю их форму. Я проверю, какие поля они хотят каждый Если они хотят имя, я дам им имя.Если они хотят адрес, я дам им адрес.Если они хотят номер заказа, я дам им номер заказа. И если у них есть какие-то PRE-POPULATED поля (или даже " скрытые "поля), я отправлю их обратно, и я пошлю его в кодировке, которую они просили, при условии, что я поддерживаю ее, URL, который я получил из поля действия тега FORM.".

Вы можете видеть в первом случае, вы ПРЕДОСТАВЛЯЕТЕ, что они хотят эту полезную нагрузку каждый раз. Точно так же, как если бы вы были жесткими кодировками. В то время как со вторым, возможно, они решили, что имя и адрес являются избыточными, поэтому они больше не просят об этом. Возможно, они добавили некоторые хорошие настройки по умолчанию для новых функций, которые вы еще не можете поддерживать. Может быть, они изменили кодировку на многочастную? Или изменился URL-адрес конечной точки. Кто знает.

Вы можете отправлять только то, что знаете, когда кодируете клиента, не так ли? Если они меняют вещи, тогда вы можете делать только то, что можете сделать. Если они добавят поля, мы надеемся, они добавят поля, которые не требуются. Но если они нарушают интерфейс, эй, они нарушают интерфейс, и вы можете регистрировать ошибку. Не так много вы можете там сделать.

Но чем больше вы используете часть HATEOS, тем больше она вам предоставляет, поэтому вы можете быть более гибкими: формы для заполнения, правильные переадресации, обращая внимание на кодирование и типы носителей, тем более гибкими ваши клиент становится.

В конце концов, большинство людей просто не делают этого в своих клиентах. Они жестко кодируют черт из них, потому что это просто, и они полагают, что задняя часть не изменяется достаточно быстро, чтобы иметь значение, или что любое время простоя, если такое изменение происходит, приемлемо, пока они не исправят клиента. Более типично, особенно с помощью внутренних систем, вы просто получите электронное письмо от разработчиков: «Они меняли XYZ API, и он будет работать 1 марта. Обновите своих клиентов и координируйте их с командой разработчиков во время тестирования интеграции. Kthx».

Это просто реальность. Это не значит, что вы не должны этого делать, или что вы не должны делать ваши серверы более дружелюбными к более умным клиентам. Помните плохого клиента, который предполагает, что все не делает недействительной хорошую систему на основе REST. Эти системы отлично работают с ужасными клиентами. wget ftw, а?