HTML-интерфейс для веб-службы RESTful * без * javascript

Question

Даже если я предлагаю альтернативы PUT и DELETE (cf «Low REST»), как я могу предоставить удобную для пользователя проверку формы для пользователей, которые обращаются к моему веб-сервису из браузера, в то же время подвергая RESTful URI? Проблема проверки формы (описанная ниже) - это мое текущее quandry, но более широкий вопрос, который я хочу задать, заключается в следующем: если я пойду по пути, чтобы предоставить как открытый интерфейс RESTful , так и интерфейс HTML без javascript, это собирается ли жизнь легче или тяжелее? Они вообще играют вместе?

Теоретически это должно быть просто вопросом изменения формата вывода. Машина может запросить URL «/ people» и получить список людей в XML. Пользователь может указывать свой браузер на один и тот же URL-адрес и вместо этого получать хороший ответ HTML. (Я использую URL examples from the microformats wiki, которые кажутся довольно разумными).

Создание ресурса нового человека выполняется с запросом POST на URL «/ people». Чтобы достичь этого, пользователь может сначала посетить «/ people/new», который возвращает статическую HTML-форму для создания ресурса. Форма имеет метод = POST и action = "/ people". Это будет работать нормально, если вход пользователя действителен, но что делать, если мы выполняем проверку на стороне сервера и обнаруживаем ошибку? Дружелюбным было бы вернуть форму, заполненную данными, которые только что введенный пользователь, плюс сообщение об ошибке, чтобы они могли исправить проблему и повторно отправить ее. Но мы не можем вернуть этот вывод непосредственно из POST в «/ people» или он нарушает нашу систему URL-адресов, и если мы перенаправляем пользователя обратно в форму «/ people/new», тогда нет способа сообщить об ошибке и повторно заполнить форму (если мы не сохраним данные в состояние сеанса, что будет еще меньше RESTful).

С javascript все будет намного проще. Просто выполните POST в фоновом режиме, и если он не удался, отобразите ошибку в верхней части формы. Но я хочу, чтобы приложение грамотно деградировало, когда поддержка javascript недоступна. На данный момент я пришел к выводу, что нетривиальное веб-приложение не может реализовать интерфейс HTML без javascript, и использовать обычную схему URL-адресов RESTful (например, описанную в викторике микроформатов). Если я ошибаюсь, скажите мне об этом!

Похожие вопросы на переполнение стека (ни один из которых имеют дело с проверкой формы):

• How to send HTML form RESTfully?
• How do you implement resource "edit" forms in a RESTful way?

Answer 1

у вас может быть сообщение формы html прямо в/people/new. Если проверка не удалась, повторно заполните форму редактирования соответствующей информацией. Если это удастся, переместите пользователя на новый URL. Это будет соответствовать архитектуре REST, насколько я понимаю.

Я видел, что вы прокомментировали Монис Икбал, и я должен признать, что я не знаю, что вы подразумеваете под «не-RESTful URLS». Единственное, что архитектура REST запрашивает у URL-адреса, заключается в том, что она непрозрачна и что она уникально сопряжена с ресурсом. REST не волнует, как это выглядит, что в нем, как слэш или используется, сколько используется, или что-то в этом роде. Видимый дизайн URL-адреса зависит от вас, а REST не имеет никакого отношения.

Answer 2

Почему бы не использовать AJAX, чтобы сделать работу на стороне клиента, и если javascript отключен, тогда создайте html, чтобы обычный POST работал.

Answer 3

Спасибо за ответы.Они немного освободили мой разум, и поэтому в ответ на мой собственный вопрос я хотел бы предложить альтернативный набор RESTful URL-соглашения, которые на самом деле охватывают два метода (GET и POST) мира, отличного от AJAX, вместо того, чтобы пытаться обойти их.

Редактировать: Как отмечают комментаторы, эти «соглашения» не должны быть частью самого RESTful API. С другой стороны, внутренние соглашения полезны, поскольку они делают реализацию на стороне сервера более последовательной и, следовательно, проще для разработчиков понимать и поддерживать. Однако клиенты RESTful должны обрабатывать URL как непрозрачные и всегда получать их как гиперссылки, никогда не создавая сами URL.

GET/люди
        возвращает список всех записей
GET/людей/нового
        возвращения формы для добавления новой записи
POST/людей/новое
        создать новую запись
        (за HTML клиента, вернуть форму снова, если вход является недействительным, в противном случае перенаправление на новый ресурс)
GET/люди/1
        возвращение первая запись
GET/люди/1/редактировать
        возвращения формы для редактирования первой записи POST/человек/1/редактировать
        обновление первая запись
GET/люди/1/удалить
        возвращающие форму для удаления записи
        (может быть просто подтверждение - вы уверены, что хотите удалить?)
POST/pe Опле/1/удалить
        удалить запись

Существует закономерность здесь: GET на ресурсе, например, «/ people/1», возвращает сама запись. Функция GET on resource + возвращает форму HTML, например. "/ Люди/1/редактировать". POST на ресурсе + операция фактически выполняет операцию.

Возможно, это не так элегантно, как использование дополнительных HTTP-глаголов (PUT и DELETE), но эти URL-адреса должны хорошо работать с ванильными форматами HTML. Они также должны быть довольно понятными для человека ... Я сторонник идеи, что «URL-адрес является частью пользовательского интерфейса» для пользователей, обращающихся к веб-серверу через браузер.

P.S. Позвольте мне объяснить, как я буду удалять. В представлении «/ people/1» будет ссылка на «/ people/1/delete» с обработчиком javascript onclick. При включенном javascript щелчок перехватывается, и пользователю предоставляется окно подтверждения. Если они подтверждают удаление, отправляется POST, сразу удаляя запись. Но если javascript отключен, щелчок по ссылке вместо этого отправит запрос GET, который возвращает форму подтверждения удаления с сервера, и , что форма отправляет POST для выполнения удаления. Таким образом, javascript улучшает пользовательский интерфейс (более быстрый ответ), но без него веб-сайт изящно деградирует.

Answer 4

Почему вы хотите создать второй «API» с помощью XML?

Ваш HTML содержит данные, которые должен видеть пользователь. HTML относительно легко разобрать. Атрибут class может использоваться для добавления семантики в виде микроформатов. Ваш HTML содержит формы и ссылки, чтобы иметь доступ ко всем функциям вашего приложения.

Зачем вам создавать другой интерфейс, который предоставляет полностью семантическое бесплатное приложение/xml, которое, скорее всего, не содержит гипермедийных ссылок, так что теперь вам придется жестко кодировать URL-адреса в своем клиенте, создавая неприятную связь?

Если вы можете заставить свое приложение работать с использованием HTML в веб-браузере без необходимости хранения состояния сеанса, то у вас уже есть RESTful API. Не убивайте себя, пытаясь создать кучу URL-адресов, которые соответствуют чьей-то идее стандарта.

Вот quote от Роя Филдинг,

Отдыхает API не должно определить фиксированные имен ресурсов или иерархии

Я знаю, что летит в лице, вероятно, почти в каждом примере REST что вы видели, но это потому, что все они неправы. Я знаю, что я начинаю звучать как религиозный фанатик, но он убивает меня, чтобы увидеть, как люди борются за дизайн API RESTful, когда они начинают совершенно ошибочную ногу.

Слушайте Бретон, когда он говорит: «REST не волнует, как выглядит [url]», и вскоре @Wahnfrieden расскажет вам то же самое. Эта страница микроформатов является ужасным советом для тех, кто пытается сделать REST. Я не говорю, что это ужасный совет для кого-то, создающего какой-то другой API-интерфейс HTTP, просто не RESTful.