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

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

API Question

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

# anchors

  


# forms


# lists

    
property
    
value

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

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

Вопрос клиента

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

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

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

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