Правильные заголовки для PHP RESTful Application? - PullRequest
Новая
       6

Правильные заголовки для PHP RESTful Application?

5 голосов
/ 22 декабря 2011

Цель: API-интерфейс RESTful
Вопрос: Является ли метод, который у меня ниже настоящего API-интерфейса RESTful, или в нем отсутствует что-то, как мне сказали?
Этовопрос из 3 частей ..

Давайте предположим, что у меня есть проект PHP, в котором есть API, который возвращает данные в форматах XML или JSON, вы можете получить доступ к API, как показано ниже ... 

server.com/article/123 | Returns ID 123 using GET
server.com/article/new | Creates a new article using POST
server.com/article/123/edit | Edits an article with the ID 123 using POST
server.com/article/123/delete | Deletes article with ID 123 using POST

1)
Я всегда читал также, что PUT должен использоваться для редактирования объектов, ниже я помещаю слово POST, поскольку пользователь отправляет POST в URI для tht длядействие удаления, должен ли я использовать PUT в php, используя вместо этого что-то подобное? 

$_PUT  = array();  
if($_SERVER['REQUEST_METHOD'] == 'PUT') {  
    parse_str(file_get_contents('php://input'), $_PUT);  
}

2)
Мне сказали в вопросе, который я написал на SOНекоторое время назад, что это похоже на RESTful API, но это не так, ответ, который я получил, был следующим:

In short, your service is not RESTful, but it is close. Rather than specify actions (edit, delete, ...) in URL segments, you will want to make use of HTTP verbs (GET, PUT, POST, DELETE).

Либо парень не знал, кто он такойговорить или я НЕ ПОЛУЧАЮ ЭТОГО, прочитав бесчисленные статьи на эту тему и сравнив каждый API, который я могу найти, как яМой пример выше НЕ RESTful?

Я хотел бы создать API RESTful, пожалуйста, помогите мне исправить приведенный выше пример, если это необходимо?

3)
Такжепри условии, что я планирую вернуть пользователю ответ JSON с чем-то вроде этого ... 

<?php
header('HTTP/1.1 200 OK');  
header('Content-type: application/json');

$data = // my code that returns the appropriate data;

echo json_encode($data);
?>

Это правильный способ вернуть результат пользователю или я что-то упустил?Многие статьи и вопросы говорят о концепции, но не попадают в реальный код, как мои примеры.

Ответы [ 2 ]

5 голосов
/ 22 декабря 2011

Чтобы ответить на часть 2 вашего вопроса, более RESTful URL и структура метода будут иметь следующий вид:

  • server.com/articles/123 - GET: вернуть товар
  • server.com/articles/123 - PUT: заменить статью на текст в теле запроса
  • server.com/articles/123 - DELETE: удалить статью
  • server.com/articles/ - POST: создать новую статью

Идея в том, что URL представляет сам ресурс (в данном случае статью), а глагол, где это практически возможно, указывает, что вы хотите с ним сделать. Лучший пример, который я могу вспомнить в дикой природе true RESTful API, - это последняя версия GitHub API : насколько я видел, они используют методы HTTP, коды ответов и пользовательские типы MIME соответственно.

В ответ на часть 3 вашего вопроса это, безусловно, правильный способ сделать это, но если бы вы использовали пользовательский тип MIME, такой как application/vnd.myawesomesite.article+json, это облегчило бы интерпретацию на стороне клиента, поскольку клиент может использовать тип MIME, чтобы определить, как анализировать результат: например, клиент может отправлять данные различным десериализаторам и классам в зависимости от представленного типа MIME. Опять же, ребята из GitHub приводят несколько примеров в своих документах API .

2 голосов
/ 22 декабря 2011
  1. Вы должны иметь возможность использовать $_POST в запросе PUT, если в запросе содержится правильный заголовок Content-Type.Это универсальный суперглобальный элемент, который всегда должен заполняться, когда отправляется тело HTTP и используется правильный заголовок Content-Type.На самом деле, он может даже появиться при неправильном запросе GET.
  2. Ваши URL могут быть более RESTful.Например, server.com/article/123 может содержать не только GET, но также POST (редактировать) и DELETE (удалять).Нет необходимости использовать отдельные URL-адреса, если вы уже используете разные методы запроса.
  3. RESTful в основном описывает способ связи между клиентом и сервером, а не то, как он это делает.Я не видел, чтобы заголовок 201 часто использовался в прошлом - обычно достаточно 200 OK.Конечно, ничто не должно помешать вам использовать код 201.

# protip: оберните все ваши данные в результирующий объект, например {'success':true,'result':<the result>,'resulttype':'article'}.Разработчики, использующие ваш API (если вы его опубликуете), сочтут это полезным.Для вас это означает, что вы можете легко добавить дополнительную информацию к ответу.

Очень интересная статья о REST API FourSquare

...