Я прочитал много полезных руководств для PHP.
(Я не хочу углубляться в то, почему я не использую RoR. Это связано с тем, что команда более знакома с PHP)
Поскольку мы планируем дальнейшее расширение использования API-интерфейсов, я прочитал, что важно внедрять Restful web-сервисы.
Я рассмотрел такие обучающие программы, как
http://www.gen-x-design.com/archives/create-a-rest-api-with-php/
По-видимому, успокаивающее средство предназначено для веб-сервисов.
Как насчет веб-страниц? могут ли они быть RESTFUL?
если ответ НЕТ, пожалуйста, не выходите за эту строку И просто скажите мне. Спасибо.
Я знаю, чтобы URL-адреса выглядели как RESTFUL urls – просто использовать mod_rewrite. Тем не менее, я уверен, что спокойная архитектура выходит за рамки простого написания URL-адресов.
Например, у меня есть список элементов на веб-странице, называемой list.php. У каждого элемента есть ссылка для удаления рядом с ним. Например, list.php? Id = 1 & deleteitem
Случается, что когда кто-то нажимает на ссылку list.php? Id = 1 и deleteitem, я, конечно же, возвращаюсь к тому же файлу list.php и проверяю параметр deleteitem в $ _GET.
Если обнаружено, я удалю из базы данных на основе идентификатора param в $ _GET.
После чего я перенаправляю обратно в list.php без каких-либо параметров.
Мне интересно, как я могу сделать весь этот поток RESTFUL?
Я прошу, потому что в REST, чтобы удалить что-то, вам нужно использовать метод HTTP-запроса (DELETE).
Очевидно, что в моих ссылках они просто просто <a href="list.php?id=1&deleteitem">Delete</a>
Пожалуйста, просветите меня.
Мое программирование не настолько сильное, и было бы хорошо, если бы приведенный совет мог быть как можно скорее.
Спасибо.
РЕДАКТИРОВАТЬ
У меня есть 2 вопроса.
вопрос 1) Поскольку это список элементов с подкачкой, как выглядит URL-адрес, если я хочу сделать его RESTful?
вопрос 2) Поскольку я помещаю ссылки DELETE рядом с каждым из элементов в списке, я понимаю, теперь я должен использовать
<form method="POST"> <input type=hidden name="_method" value="delete"> <input type="submit" > </form>
вместо.
однако форма должна быть отправлена туда, где? пункт url? / Детали / {идентификатор записи}
Но я хочу вернуться к этой странице с отображением успешного сообщения ПОСЛЕ успешного удаления строки в базе данных.
Я также хочу избежать всплывающего сообщения, когда обновляю страницу с успешным сообщением.
Если я вернусь к этому списку list.php, то это не RESTful да? потому что в ответах ниже сказано, что каждый элемент – это ресурс, который нуждается в собственном URL-адресе.
Пожалуйста, просветите меня. Спасибо.
RESTful обычно используется при обращении к веб-службам, но он может очень хорошо применяться к веб-страницам. В двух словах, будучи RESTful, мы имеем дело с ресурсами. Ресурсом может быть человек, книга, фильм, театр, билет или все, что вам нравится.
Существует четыре основных операции, которые вы можете выполнить на ресурсе.
Большинство веб-браузеров не поддерживают действия PUT и DELETE , поэтому вы можете использовать только действия POST для отправки данных. Rails подделывает PUT и DELETE, передавая скрытый параметр с именем _method который _method его в зависимости от этого значения.
Кроме того, вы никогда не должны использовать GET для каких-либо деструктивных действий. Любое действие, которое изменяет состояние вашего ресурса (-ов), должно быть вызвано с помощью POST , PUT или DELETE зависимости от изменения (подделка PUT / DELETE с помощью POST, если потребуется).
Я бы предложил вам проверить, как RESTful-маршрутизация обрабатывается в Rails только для того, чтобы получить представление, если ничего другого. Несмотря на то, что четыре вышеуказанных действия достаточно, чтобы каким-либо образом модифицировать ресурс, Rails также вводит три других типа действий, которые полезны.
Довольно URL-адрес определенно находится на столе при разработке сайтов RESTful, но, вероятно, самая большая победа в том, что качество кода улучшается автоматически. Когда вы имеете дело только с ресурсами, и есть только четыре потенциальных действия, которые могут быть применены к ресурсу, тогда все начинает самостоятельно очищаться.
Изменить 1 : самоописательные URL-адреса предпочтительнее и облегчат вашу жизнь, но нет ничего, что могло бы остановить создание загадочных URL-адресов, которые однозначно идентифицируют ресурс и управляют им с помощью глаголов HTTP. URL-адреса, такие как приведенные ниже (с использованием md5) для уникальной идентификации ресурсов, отлично RESTful.
// represents a person "John Doe" http://example.com/4c2a904bafba06591225113ad17b5cec // represents the movie "Lord of the Rings: The Two Towers" http://example.com/1d9198260dec7bda3fb21e232d60fec3 // represents the "Formula One" sport http://example.com/fs340as?id=23xa12&type=SP012Ts
Это прямое государственное трансфер прямо там. Хэш MD5 похож на почтовый адрес ресурса, который остается постоянным. Представление может быть деталями фильма (в html / xml / json / etc.), Или, возможно, видео самого фильма в зависимости от возможностей клиента).
Изменить 2 : Предположим, у вас есть ресурс, который представляет собой коллекцию – countries мира. Он может быть представлен URI и HTTP-глаголом, например:
GET /countries
Поскольку пейджинг – это свойство приложения, а не самого ресурса, вы можете указать параметры запроса для его контроля.
GET /countries?page=1
Страна также является ресурсом, который является частью ресурса стран. Вы можете указать страну с URL-адресом, таким как:
/countries/<id>
И операции над этой страной могут выполняться с помощью этих глаголов:
GET /countries/<id> POST /countries -- the new country has no existing representation PUT /countries/<id> DELETE /countries/<id>
Длинный ответ короткий: да. REST для обоих. Это потому, что даже если у вас есть самый простой из всех веб-сайтов, вам все равно придется ПОЛУЧИТЬ вашу страницу и, возможно, POST-личные данные, чтобы добавить запись в гостевую книгу. В этом мы все как-то придерживаемся REST.
В вашем случае неудачная реализация браузера затрудняет реализацию способа PURE RESTful. DELETE не поддерживается без Javascript, поэтому вам придется использовать GET или POST (которые оба имеют совершенно иное значение от DELETE в REST) в любом случае.
Надежный подход, безусловно, можно использовать и на веб-страницах. Помещение команд в URL-адрес – не очень хорошая идея из-за побочных эффектов, которые вы упоминаете. Когда вы меняете базу данных (или делаете то, что меняет модель), используйте команды POST.
Конечно, у вас нет PUT и DELTE в основных веб-браузерах, но вы всегда можете отправить простой POST с некоторыми конкретными параметрами, такими как method = "PUT", method = "DELETE" и т. Д.
Я написал крошечную структуру поверх Zend Framework, чтобы упростить реализацию интерфейсов RESTful:
http://github.com/mikekelly/Resauce
Вы можете использовать это для веб-сервисов и веб-сайтов. По сути, веб-сайт – это просто веб-сервис, управляемый HTML.
RESTful означает не «красивые URI». Несмотря на то, что URI идентифицируют ресурс, единственное, что REST говорит об URI, заключается в том, что они не должны содержать параметр действия, например «delete».
В вашем случае вы позвонили бы
DELETE /items/6793
Ответ будет обычно кодом состояния 200 OK с измененным списком в качестве тела сообщения. См .: http://restpatterns.org/HTTP_Methods/DELETE
Поскольку HTML 4 не поддерживает другие действия формы, чем GET и POST, вы должны обходиться со скрытым параметром и переопределять метод HTTP на стороне сервера.