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

7

Я разработал очень быстрое и простое 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, содержащий список полей ввода?

  • 0
    Что касается ваших дополнительных вопросов: да, вы можете поместить switch в ваш index.php, или, если вы хотите перейти на более сложную архитектуру, вы можете запустить внешний компонент маршрутизатора, который обрабатывает маршрутизацию. Разбор URI был только для справки - я не думаю, что он понадобится вам для вашего приложения. Учитывая простоту вашего приложения, вы можете просто проанализировать и направить метод запроса для редактирования вашего отдельного файла. Это все равно будет RESTful.
  • 1
    В более общем смысле, RESTfulness касается интерфейса , а не реализации .
Теги:
rest

2 ответа

15
Лучший ответ

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

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

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

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

1 - МЕТОД ЗАПРОСА

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

  • POST
  • GET
  • PUT
  • DELETE

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

  • PATCH
  • ГОЛОВКА

Вы можете сопоставить их непосредственно с вашими действиями 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 (e.g. UserController) via __autoload
// or to a file (e.g. user.php) via include, and pass id and content_type as params

4 - БЕЗОПАСНОСТЬ Проще говоря, сервер не поддерживает "состояние" для клиента. Нет требований для хранения сеанса или состояния. Каждый запрос представляет собой полную транзакцию. То есть если я GET user/1, сервер не запомнит, что я сделал это, а будущие запросы не будут зависеть от предыдущих или не будут затронуты предыдущими.

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

Поделиться
  • 0
    очень хороший ответ, поздравляю!
  • 0
    Большое спасибо за ваш подробный ответ. Я вижу, что вы немного его отредактировали, и время, которое вы потратили, высоко ценится. У меня есть еще несколько уточняющих вопросов, в которых я отредактировал, если вы могли бы взглянуть.
Показать ещё 3 комментария
4

"RESTful" - это широкая концепция, и есть степени "RESTfulness". Wikipedia является хорошим ориентиром здесь

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

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

Ещё вопросы

Сообщество Overcoder
Наверх
Меню