PHP Lang
  1. PHP Lang
  3. Создать RESTful API в PHP?
Intereting Posts
Проверьте, не сериализована ли строка? PHP включает vs include_once (скорость) извлечение идентификаторов, назначенных списку идентификаторов пользователей Условный элемент внутри массива (…) отображать данные из базы данных в определенном порядке: php или mysql? Laravel 4: добавить whereIn в условие соединения Когда нужно закрыть соединение с базой данных в PHP? Php: преобразовать blob в файл изображения Неопределенный индекс при загрузке файла Как уловить вложенные {% if …%} {% endif%} статусы с регулярным выражением Возвращение ответа JSON из запроса MySQL URL-адрес запроса php, не дожидаясь ответа Методы для класса исключения Xdebug PHP exec () использование памяти Как заблокировать прямой доступ к моим файлам JavaScript?

Создать RESTful API в PHP?

Я разработал очень быстрое и простое приложение PHP для чтения классифицированных объявлений из XML-файла и позволяющее пользователю выполнять операции CRUD на нем (это было домашнее задание).

Теперь мне поручено разработать это приложение для службы RESTful. У профессора, похоже, нет никакого опыта работы с услугами RESTful, потому что он сказал, что мое приложение было найдено для передачи следующего задания, когда мои исследования показывают, что он действительно не выполняет все требования RESTful.

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

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

Например, вот как я создаю новые объявления.

create.php 

//Basically just a list of <INPUT TYPE = "text" NAME = "something"> in the <body> fields

CreateSuccess.php 

 <html><head><?php $simplerXML = simplexml_load_file('file.xml'); //Generate the basic ad information $newAd = $simplerXML->addChild('advertisement',''); $newAd->addAttribute('category', $_POST["category"]); $title = $newAd->addChild('title', $_POST["title"]); $title->addAttribute('ID', $_POST["ID"]); $pageTitle = $newAd->addChild('pagetitle', $_POST["pagetitle"]); //etc, for all the SUBMIT boxes //save the XML $simplerXML->asXML('file.xml'); echo "<script type='text/javascript'> //redirect back to ad listing page window.onload = function () { top.location.href = 'ads.php'; }; </script>"; ?></head> <body></body></html>

Я также использую параметры URL для действий RUD. Я слышал, что параметры URL не разрешены?

Благодарю.

EDIT: Итак, инструкция SWITCH, идет ли она в файл index.php? И тогда каждый случай вызовет функцию, т. Е. CreateXML для метода POST? Тогда нужны ли ему параметры типа объекта, идентификатора объекта и типа содержимого? Как мне получить значения для обновления XML, просто я отправил его в файл Create.php, содержащий список полей ввода?

Если ваша служба поддерживает все операции CRUD, всегда рекомендуется реализовать интерфейс RESTful. Это не сложно. Я изложил некоторые из основ ниже.

Служба RESTful просто делает несколько вещей:

  1. Он использует метод HTTP-запроса для связи действия CRUD
  2. Он использует код состояния HTTP для передачи статуса ответа и
  3. Он использует URI для определения вашего ресурса (файл, элемент базы данных, к которому вы обращаетесь, и т. Д.).
  4. Он без гражданства

Идея состоит в том, чтобы свести к минимуму разработку пользовательских сообщений для этих вещей, которые уже определены в спецификации HTTP.

1 – СПРАВОЧНЫЙ МЕТОД

4 метода HTTP-запроса, которые необходимы для поддержки службы RESTful:

  1. ПОСЛЕ
  2. ПОЛУЧИТЬ
  3. ПОЛОЖИЛ
  4. УДАЛИТЬ

и вы можете опционально поддерживать

  1. PATCH
  2. ГЛАВА

Вы можете сопоставить их непосредственно с вашими действиями CRUD следующим образом:

  • POST = Создать
  • GET = Получить
  • PUT = Обновить
  • DELETE = Удалить
  • PATCH = Edit (частичное обновление, например «сменить пароль». PUT становится «заменой»)
  • HEAD = Только заголовок (метаданные об ресурсе)

Чтобы сделать это, правильно запрограммируйте запросы с помощью простого маршрутизатора метода запросов следующим образом: 

 switch ($_SERVER["REQUEST_METHOD"]) { case "POST": // Create action break; case "GET": // Retrieve action break; case "PUT": // Update action break; case "DELETE": // Delete action break; }

2 – КОД СОСТОЯНИЯ. Вы должны дополнительно ввести коды состояния HTTP из своей службы, чтобы передать статус клиенту, например:

  • 20x = успех
  • 30x = перенаправление
  • 40x = проблемы связи
  • 50x = ошибка сервера

Для этого просто добавьте ответ с соответствующим заголовком HTTP-заголовка, например: 

 header("Status: 500 Internal Server Error");

Вы можете ссылаться на полный список реализованных кодов состояния HTTP здесь: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

3 – URI для URI, службы RESTful обычно следуют принципу сверху вниз для категоризированного наименования, например 

 /object_type/id.content_type

Примеры: 

 POST /user PUT /user/1 GET /user/1.json GET /user/1.html

Вы можете реализовать очень рудиментарный маршрутизатор RESTful для вышеупомянутого соглашения, используя Apache с mod_rewrite в файле .htaccess , а именно: 

 RewriteEngine On RewriteRule ^([^\/]+)\/([^\.]+)\.(\w+)$ index.php?object_type=$1&object_id=$2&content_type=$3

Тогда у вас будет index.php Ищите подходящий object_type и id для правильной маршрутизации, например: 

 $object = $_GET["object_type"]; $id = (int) $_GET["object_id"]; $content_type = $_GET["content_type"]; // Route from here to a class with the name of the object (eg UserController) via __autoload // or to a file (eg user.php) via include, and pass id and content_type as params

4 – СТАТИСТИКА Просто заявлено, что сервер не поддерживает «состояние» для клиента. Нет требований для хранения сеанса или состояния. Каждый запрос представляет собой полную транзакцию. Т.е. если я GET user / 1, сервер не запомнит, что я сделал это, а будущие запросы не будут зависеть от предыдущих или не будут затронуты предыдущими.

Если вы примете эти стандарты, поздравляйте, вы создали службу RESTful!

«RESTful» – это широкая концепция, и есть «RESTfulness». Википедия – хорошее руководство здесь

Вот некоторые более высокоуровневые характеристики, которые не рассматриваются в другом ответе (что тоже хорошо):

  1. Ресурсы доступны по URL-адресам, предпочтительно с одним каноническим URL-адресом на ресурс.
    • Вы можете указать, что ресурс доступен в других URL-адресах или представлениях, используя заголовок Content-Location .
    • Вы можете предоставить различные представления ресурса (html, json, xml и т. Д.), Используя согласование содержимого с заголовками Accept и content-type .
  2. Изменения состояния ресурса полностью представлены одним HTTP-запросом. Серверу не нужно поддерживать состояние для обслуживания запроса клиента. Следовательно, запросы могут быть легко проксированы и кэшированы.
    • Примером общего нарушения этого принципа является URL-адрес, например «http://example.org/profile&#xBB;, который обслуживает другой профиль пользователя в зависимости от того, кто вошел в систему.
    • Лучше было бы отделить ресурс от авторизации: «http://example.org/profile/{USERID» всегда будет обслуживать пользовательский идентификатор конкретного пользователя, но возвращает 401 (не авторизован), если у клиента нет разрешения. (Кроме того, информация авторизации должна быть отправлена ​​с каждым запросом, так что сервер не требует маркера сеанса или аналогичного состояния на стороне сервера. Как следствие, большинство сайтов с системой входа в систему на основе файлов cookie не являются исключительно спокойными.)
    • GET для получения ресурса. Это не должно изменять состояние ресурса и должно быть безопасно воспроизводимым. Это свойство часто называют «Идемпотентность».
    • PUT для обновления ресурса. Используя такие методы, как запросы условного обновления (PUT или DELETE с заголовком if-* ), вы даже можете реализовать оптимистичный контроль параллелизма.
    • УДАЛИТЬ, чтобы удалить ресурс.
    • POST как ресурс «сделать что-то». POST используется, когда вам нужно сделать что-то, что не соответствует чисто методам http или когда вам нужно выполнить действие с побочными эффектами (например, создать новый ресурс, не зная его имени или реализовать протокол RPC). Тем не менее, вы должны использовать заголовки HTTP и коды ответов, чтобы показать, какие побочные эффекты были там, например, «201 создан» с заголовками « Location и Content-Location и список URL-адресов, затронутых изменением.
  3. Представления ресурсов являются самоописательными «гипертекстами» со ссылками на другие ресурсы.
    • Пример нарушения этого принципа: предположим, что «http://example.com/articles&#xBB; – это список статей, а json-представление выглядит как [1,2,3,4,5,6] . Это список идентификаторов статей, но он не является самоописательным или гипертекстом – клиенту необходимо знать, что это список идентификаторов статей, и ему нужно знать, что для получения ресурса статьи он должен построить URL-адрес, например, http://example.org/articles/1&quot; .
    • Лучше будет ответ вроде {"articles":[{"id":1,"url":"http://example.org/articles/1"},...]} . Как и html, клиенту, использующему службу отдыха, нужно только следить за ссылками (не создавать ссылки), чтобы получить доступ к другим связанным ресурсам. Вы даже можете документировать доступные методы, которые вы можете использовать для управления ресурсом – создавать, обновлять, удалять и т. Д.