Интерфейс HTML к УСПОКОИТЕЛЬНОМУ веб-сервису *без* JavaScript
Я думаю, что большинство поставщиков дб не позволяет DROP TABLE * (или подобный).
я думаю, что лучший способ состоял бы в том, чтобы ПОКАЗАТЬ ТАБЛИЦЫ и затем пройти каждое удаление в цикле через набор результатов.
HTH.
4 ответа
вы можете разместить сообщение формы html непосредственно в / people / new. Если проверка не удалась, повторно отрендерите форму редактирования с соответствующей информацией. Если это удастся, перенаправьте пользователя на новый URL-адрес. Насколько я понимаю, это согласуется с архитектурой REST.
Я видел, как вы комментировали Монис Икбал, и должен признать, что не понимаю, что вы имеете в виду под «URL без RESTful». Единственное, что архитектура REST требует от URL-адреса, - это чтобы он был непрозрачным и был уникальным образом связан с ресурсом. REST не заботится о том, как он выглядит, что в нем, как косая черта или используется, сколько используется, или что-то в этом роде. Внешний вид URL-адреса зависит от вас, и REST не имеет значения.
Спасибо за ответы. Они немного освободили мой разум, и поэтому в ответ на свой вопрос я хотел бы предложить альтернативный набор RESTful соглашений об URL, которые на самом деле охватывают два метода (GET и POST ) в мире, отличном от AJAX, вместо того, чтобы пытаться обойти их.
Изменить: Как отмечали комментаторы, эти «соглашения» не должны быть частью самого RESTful API. С другой стороны, внутренние соглашения полезны, потому что они делают реализацию на стороне сервера более согласованной и, следовательно, более простой для разработчиков для понимания и поддержки. Однако клиенты RESTful должны рассматривать URL-адреса как непрозрачные и всегда получать их как гиперссылки, никогда не создавая самих URL-адресов.
(для клиента HTML верните форму еще раз, если введенные данные недействительны, в противном случае выполните перенаправление на новый ресурс)
GET / people / 1
возвратит первую запись
GET / people / 1 / edit
вернуть форму для редактирования первой записи
POST / people / 1 / edit
обновить первую запись
GET / people / 1 / delete
вернуть форму для удаления записи
(может быть просто подтверждением - вы уверены, что хотите удалить?)
POST / people / 1 / delete
удалить запись
Здесь есть шаблон: GET для ресурса, например "/ people / 1 ", возвращает саму запись. Операция GET для ресурса + возвращает HTML-форму, например, «/ people / 1 / edit». Операция POST on resource + фактически выполняет операцию.
Возможно, это не так элегантно, как использование дополнительных HTTP-команд (PUT и DELETE), но эти URL-адреса должны хорошо работать с обычными HTML-формами. Они также должны быть довольно понятными для человека ... Я верю в идею, что «URL-адрес является частью пользовательского интерфейса» для пользователей, обращающихся к веб-серверу через браузер.
PS Позвольте мне объяснить как бы я удалил. В представлении "/ people / 1" будет ссылка на "/ people / 1 / delete", с обработчиком javascript onclick. При включенном javascript щелчок перехватывается, и пользователю предоставляется окно подтверждения. Если они подтверждают удаление, отправляется POST-запрос, немедленно удаляющий запись. Но если javascript отключен, нажатие на ссылку вместо этого отправит запрос GET, который возвращает форму подтверждения удаления с сервера, а эта форма отправляет POST для выполнения удаления. Таким образом, javascript улучшает взаимодействие с пользователем (более быстрый ответ), но без этого веб-сайт постепенно ухудшается.
и форма отправляет POST для выполнения удаления. Таким образом, javascript улучшает взаимодействие с пользователем (более быстрый ответ), но без этого веб-сайт постепенно ухудшается. и форма отправляет POST для выполнения удаления. Таким образом, javascript улучшает взаимодействие с пользователем (более быстрый ответ), но без этого веб-сайт постепенно ухудшается.Почему вы хотите создать второй «API» с использованием XML?
Ваш HTML-код содержит данные, которые должны видеть ваш пользователь. HTML относительно легко анализировать. Атрибут class может использоваться для добавления семантики, как это делают микроформаты. Ваш HTML-код содержит формы и ссылки для доступа ко всем функциям вашего приложения.
Зачем вам создавать другой интерфейс, который предоставляет полностью семантическое бесплатное приложение / xml, которое, вероятно, не будет содержать гипермедийных ссылок, так что теперь вам придется жестко URL-адреса кода в вашем клиенте, создавая неприятную связь?
Если вы можете заставить свое приложение работать с использованием HTML в веб-браузере без необходимости сохранять состояние сеанса, то у вас уже есть RESTful API. Не убивайте себя, пытаясь создать кучу URL-адресов, которые соответствуют чьему-то представлению о стандарте. имена или иерархии ресурсов
Я знаю, что это бросает вызов, вероятно, почти каждому примеру REST, который вы видели, но это потому, что все они неверны. Я знаю, что начинаю казаться религиозным фанатиком, но меня убивает то, что люди пытаются разработать RESTful API, когда они начинают совершенно не с той ноги.
Послушайте Бретона, когда он говорит: «REST все равно. как выглядит [URL] ", и @Wahnfrieden скоро подскажет вам то же самое. Эта страница с микроформатами - ужасный совет для тех, кто пытается использовать REST. Я не говорю, что это ужасный совет для кого-то, кто создает какой-то другой тип HTTP API, только не RESTful.
Почему бы не использовать AJAX для работы на стороне клиента, и если javascript отключен, тогда спроектируйте html так, чтобы работал обычный POST.