Как отобразить различные виды пользовательского интерфейса в веб-приложении RESTful?

Question

Я разрабатываю веб-приложение, которое будет поддерживать как стандартные пользовательские интерфейсы (доступные через браузеры), так и RESTful API (веб-сервис на основе XML / JSON). Пользовательские агенты смогут различать их, используя разные значения в заголовке HTTP Accept.

RESTful API будет использовать следующую структуру URI (пример для ресурса "article"):

• GET /article/ - получает список статей
• POST /article/ - добавляет новую статью
• PUT /article/{id} - обновляет существующую статью на основе {id}
• DELETE /article/{id} - удаляет существующую статью на основе {id}

Однако часть пользовательского интерфейса приложения должна поддерживать несколько представлений, например:

• стандартное представление ресурсов
• представление для отправки нового ресурса
• представление для редактирования существующего ресурса
• представление для удаления существующего ресурса (то есть отображение подтверждения удаления)

Обратите внимание, что к последним трем видам по-прежнему обращаются через GET, даже если они обрабатываются через перегруженные POST.

---

Возможное решение:
Ввести дополнительные параметры (ключевые слова) в URI, которые бы идентифицировали отдельные представления - то есть, в дополнение к вышесказанному, приложение будет поддерживать следующие URI (но только для Content-Type: text/html):

• GET /article/add - отображает форму для добавления новой статьи (извлекается через GET, обрабатывается через POST)
• GET /article/123 - отображает статью 123 в режиме «просмотра» (извлекается через GET)
• GET /article/123/edit - отображает статью 123 в режиме «редактирования» (извлекается через GET, обрабатывается через PUT, перегружен как POST)
• GET /article/123/delete - отображает подтверждение «удаления» для статьи 123 (получено с помощью GET, обработано с помощью DELETE, перегружено как POST)

Лучшей реализацией вышеупомянутого может быть помещение ключевых слов add / edit / delete в параметр GET - поскольку они не изменяют ресурс, с которым мы работаем, может быть лучше оставить базовый URI одинаковым для всех из них.

---

Мой вопрос:
Как бы вы отобразили вышеуказанную структуру URI на пользовательские интерфейсы, обслуживаемые обычному пользователю, учитывая, что на каждый ресурс может быть несколько представлений, пожалуйста? Согласны ли вы с возможным решением, подробно изложенным выше, или вы бы порекомендовали другой подход, основанный на вашем опыте?

Примечание: мы уже внедрили приложение, которое состоит из отдельного RESTful API и отдельного веб-приложения. В настоящее время я изучаю варианты будущих проектов, в которых эти два будут объединены (т.е. для уменьшения накладных расходов).

Answer 1

В терминах REST - «альтернативные представления» на самом деле являются просто старыми ресурсами, потому что URI непрозрачны. Отношения обнаруживаются по ссылкам от одного к другому - в этом случае; от списка статей, до статьи, чтобы редактировать и удалять эту статью. Ключевым моментом здесь является то, что на самом деле это вообще не имеет значения для вашей структуры URI, то есть следующие одинаково «правильные»:

GET /article/123/edit
GET /article/123;edit

Ответ на самом деле просто вопрос вкуса. Если они идентифицируются по URI и могут быть связаны с ними, тогда вы делаете все правильно.

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

Я бы сделал это точно так же, как работает приложение HTML - то есть, предоставив те же гиперссылки в XML, чтобы соединить / связать ресурсы (представления), чтобы клиент следовал и отображал в пользовательском интерфейсе по мере необходимости .

1012 *, например *

GET /article/foobar

200 OK
Content-Type: application/mytype+xml
....
<link rel="edit" href="/article/foobar;edit" />
....

наконец:

Согласны ли вы с возможным Решение подробно описано выше, или вы рекомендовать другой подход на основе на вашем опыте?

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

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

В целом, подход к использованию одних и тех же ресурсов для приложений на основе XML и HTML является хорошим.

Answer 2

Я не уверен, что понимаю, почему вы хотите объединить их вместе; хотя идея, кажется, имеет смысл, я думаю, что на самом деле это будет ложная экономика.

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

Разделение их может показаться дополнительной работой, но если через 4 месяца что-то произойдет, это будет еще больше, а значит, вам нужно снова разделить их. Разделение проблем выходит за рамки UI / Logic / Data.

Пока ваша логика хранится централизованно и является связной, в моей книге не будет проблемы с двумя наборами взглядов.

В качестве компромисса, можете ли вы сохранить одинаковую структуру URL для обоих представлений, но дублированную (т.е. согласованную)?