Restful предназначен только для веб-служб ИЛИ как для веб-служб, так и для веб-страниц?

Я прочитал много руководств Restful по PHP.

(Я не хочу вдаваться в подробности, почему я не использую RoR. Это связано с тем, что команда более знакома с PHP)

Поскольку мы планируем в будущем расширить API-интерфейсы, я прочитал, что важно внедрять веб-службы Restful.

Я просмотрел такие учебники, как

http://www.gen-x-design.com/archives/create-a-rest-api-with-php/

По-видимому, успокаивающий предназначен для веб-сервисов.

А как насчет веб-страниц? они тоже могут быть ОТДЫХАЮЩИМИ?

Если ответ НЕТ, пожалуйста, не выходите за эту строчку и просто скажите мне. Спасибо.

Я знаю, что сделать URL-адреса похожими на RESTFUL urls - это просто использовать mod_rewrite. Однако я совершенно уверен, что спокойная архитектура выходит за рамки простого оформления URL-адресов.

Например, у меня есть список элементов на веб-странице с именем list.php. Рядом с каждым элементом есть ссылка для удаления. Например, list.php? Id = 1 & deleteitem

Что происходит, когда кто-то нажимает на ссылку list.php? Id = 1 & deleteitem, я, конечно, возвращаюсь к тому же файлу list.php и проверяю параметр deleteitem в $ _GET.

Если обнаружено, я удалю из базы данных на основе идентификатора параметра в $ _GET.

После чего я перенаправлю обратно на list.php БЕЗ каких-либо параметров.

Мне интересно, как мне сделать весь этот поток ВОССТАНОВЛЕННЫМ?

Я спрашиваю, потому что в 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 элемента? / items / {item-id}

Но я хочу вернуться на эту страницу со списком, отображающую сообщение об успехе ПОСЛЕ успешного удаления строки в базе данных.

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

Если я вернусь к этому URL-адресу list.php, тогда это не RESTful, да? потому что ответы ниже мне говорят, что каждый элемент является ресурсом, которому нужен собственный URL-адрес.

Просвети меня, пожалуйста. Спасибо.


person Kim Stacks    schedule 06.03.2010    source источник


Ответы (5)


RESTful обычно используется при обращении к веб-службам, но вполне может применяться и к веб-страницам. Вкратце, RESTful - это работа с ресурсами. Ресурсом может быть человек, книга, фильм, театр, билет или что угодно.

Есть четыре основных операции, которые вы можете выполнить с ресурсом.

  • создать (POST)
  • читать (ПОЛУЧИТЬ)
  • обновить (PUT)
  • удалить (УДАЛИТЬ)

Большинство веб-браузеров не поддерживают действия PUT и DELETE, поэтому для отправки данных можно использовать только действия POST. Rails подделывает PUT и DELETE, передавая скрытый параметр с именем _method, который фреймворк подбирает и направляет в зависимости от этого значения.

Кроме того, вы никогда не должны использовать GET для каких-либо деструктивных действий. Любое действие, которое изменяет состояние вашего ресурса (ов), должно вызываться с помощью POST, PUT или DELETE в зависимости от изменения (если необходимо, поддельный PUT / DELETE с помощью POST).

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

  • index (просмотр списка всех элементов)
  • новый (обычно вид формы для добавления нового ресурса)
  • редактировать (обычно вид формы для обновления существующего ресурса)

При разработке сайтов RESTful обязательно используются красивые URL-адреса, но, вероятно, самым большим преимуществом является то, что качество кода улучшается автоматически. Когда вы имеете дело только с ресурсами, и есть только четыре возможных действия, которые можно применить к ресурсу, тогда все начинает очищаться само по себе.

Редактировать 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

Это REpresentational State Transfer прямо здесь. Хеш MD5 подобен почтовому адресу ресурса, который остается постоянным. Представлением могут быть детали фильма (в html / xml / json / и т. Д.) Или, возможно, видео самого фильма в зависимости от возможностей клиента).

Редактировать 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>
person Anurag    schedule 06.03.2010
comment
У меня есть вопрос. Для форм, использующих POST, я не хочу, чтобы мой пользователь видел всплывающее окно, когда он использует кнопки возврата и обновления в своем браузере. Итак, как мне преодолеть это, оставаясь при этом RESTful? - person Kim Stacks; 06.03.2010
comment
ознакомьтесь с этим вопросом, чтобы узнать, как это исправить: stackoverflow.com/questions/660329/ - person Anurag; 06.03.2010
comment
У меня вопрос о просмотре списка всех товаров. Я не так хорошо знаком с Rails, поэтому должен спросить вас. Как с этим справится платформа RESTful для разбиения списков на страницы? - person Kim Stacks; 06.03.2010
comment
Итак, вы говорите, что всякий раз, когда у вас есть свойство приложения, а не сам ресурс, все равно RESTful, что я указываю его с помощью параметра URL-адреса, например? page = 1 - person Kim Stacks; 07.03.2010
comment
это мелочь ... самое главное - помнить, что составляет ресурс. если вы разбиваете по 10 стран на страницу, каждая ли страница стран представляет собой ресурс для ваших целей? если да, сделайте его частью самого URI. в противном случае укажите его в параметрах строки запроса. - person Anurag; 07.03.2010
comment
Предположим, у меня есть / country? page = 1, в котором перечислены 10 стран, и рядом с каждой страной есть ссылка УДАЛИТЬ. ссылка представляет собой отправку ввода в теге формы, который также будет иметь скрытое значение input _methodDELETE, как предложено другими ответами здесь, чтобы сделать его RESTful. Проблема в этом теге формы, каково значение действия? это RESTful URI типа / countries / ‹id›? если это так, мне нужен файл .php, который будет обрабатывать все PUT, DELETE, GET, POST, которые отправляются в страны / ‹id›, а затем читать реферальную ссылку и перенаправлять обратно, чтобы иметь возможность использовать POSTRedirectGet? - person Kim Stacks; 08.03.2010
comment
Ага. поскольку вы удаляете такой ресурс, как /countries/43, это также будет URL-адрес (действие формы). метод будет DELETE, как вы упомянули. перенаправление на /countries после завершения удаления может быть неявным знанием на стороне сервера или может быть запрошено клиентом в качестве параметра ссылки, как вы сказали. - person Anurag; 08.03.2010
comment
неявное знание на стороне сервера, означающее что-то вроде _SERVER ['HTTP_REFERER']; запрошенный клиентом в качестве параметра реферала, вы имеете в виду, как создание формы action = / country / 43? referrer = country? page = 1, извините, если мне нужно задать такие подробности. - person Kim Stacks; 08.03.2010
comment
Ой, а что по-твоему лучше? на стороне сервера или на стороне клиента? при условии, что мое понимание верное на основе моего последнего комментария - person Kim Stacks; 08.03.2010
comment
Я предпочитаю хранить все это на самой стороне сервера. Например, на стороне сервера удаление может работать как function deleteCountry() { ... ; header("Location:/countries"); } .. после того, как что-то удалено, оно не имеет представления, поэтому в идеале я бы позволил серверу решить, куда идти дальше. но это зависит от вас и ваших вариантов использования, которые могут отличаться - person Anurag; 08.03.2010
comment
так что я на правильном пути, чтобы сказать, что $ _SERVER ['HTTP_REFERER'] должен использоваться, чтобы определить, откуда исходит запрос, и соответственно перенаправить? - person Kim Stacks; 09.03.2010
comment
Я также где-то читал, что использовать $ _SESSION для аутентификации на спокойном веб-сайте не идеально. Что это обозначает? - person Kim Stacks; 09.03.2010

Длинный ответ, короткий: да. ОТДЫХ предназначен для обоих. Это потому, что даже если у вас самый простой из всех веб-сайтов, вам все равно придется ПОЛУЧИТЬ свою страницу и, возможно, отправить свои личные данные, чтобы добавить запись в гостевую книгу. В этом мы все так или иначе придерживаемся REST.

В вашем случае плохая реализация браузера затрудняет реализацию способа PURE RESTful. DELETE не поддерживается без Javascript, и поэтому вам все равно придется использовать GET или POST (которые имеют совершенно другое значение, чем DELETE в REST).

person aefxx    schedule 06.03.2010

Спокойный подход, безусловно, можно использовать и на веб-страницах. Ввод команд в URL-адрес - не лучшая идея из-за упомянутых вами побочных эффектов. Когда вы меняете базу данных (или делаете то, что меняет модель), используйте команды POST.

Конечно, у вас нет PUT и DELTE в основных веб-браузерах, но вы всегда можете отправить простой POST с определенным параметром, например method = "PUT", _2 _ = "DELETE" и т. Д.

person naivists    schedule 06.03.2010
comment
Я бы назвал параметр method = PUT или method = DELETE: D - person aefxx; 06.03.2010
comment
aefxx: хорошая идея, конечно метод имеет больше смысла, чем работа - person naivists; 06.03.2010
comment
У меня есть вопрос. Для форм, использующих POST, я не хочу, чтобы мой пользователь видел всплывающее окно, когда он использует кнопки возврата и обновления в своем браузере. Итак, как мне преодолеть это, оставаясь при этом RESTful? - person Kim Stacks; 06.03.2010
comment
Вы можете избежать дублирования отправки форм с помощью en.wikipedia.org/wiki/Post/Redirect/Get - person vsr; 06.03.2010

Я написал крошечный фреймворк поверх Zend Framework, чтобы упростить реализацию интерфейсов RESTful:

http://github.com/mikekelly/Resauce

Вы можете использовать это для веб-сервисов и веб-сайтов. По сути, веб-сайт - это просто веб-сервис, управляемый HTML.

person Mike    schedule 06.03.2010
comment
По определенным причинам мы не используем Zend Framework. Могу ли я по-прежнему использовать Resauce, чтобы помочь мне в моей ситуации, как описано выше? Спасибо. - person Kim Stacks; 07.03.2010
comment
Resauce построен из компонентов MVC ZF - так что нет. Существуют и другие проекты, такие как клей (gluephp.com/about), Limonade и т. Д. - person Mike; 07.03.2010

RESTful - это не «красивые URI». Несмотря на то, что URI идентифицируют ресурс, единственное, что REST говорит об URI, это то, что они не должны содержать параметр действия, такой как «удалить».

В вашем случае вы бы позвонили

DELETE /items/6793

Ответом обычно будет код состояния 200 OK с измененным списком в теле сообщения. См. http://restpatterns.org/HTTP_Methods/DELETE.

Поскольку HTML 4 не поддерживает другие действия с формами, кроме GET и POST, вам нужно найти обходной путь со скрытым параметром и переопределить метод HTTP на стороне сервера.

person deamon    schedule 06.03.2010
comment
даже если я использую форму POST для удаления элемента, как мне перенаправить обратно на страницу со списком? Я отредактировал свой вопрос, чтобы включить этот запрос - person Kim Stacks; 06.03.2010