Бекэнд для REST

[Silentland]

Начинаю переходить на Angular, соответственно, копать в сторону REST. Есть что-нибудь простенькое на PHP для расшифровки рест-запросов и связи с БД. Без сложных фреймворков и решений с актив рекордс?

 

[fixxxer]

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

 

[Silentland]

Ок. У меня есть клиент, работающий согласно архитектуре REST, нужно чтобы сервер его понимал и транслировал соответствующие операции в БД. Задача минимум, чтобы сервер понимал REST (читал тип запроса, парсил URL... что там еще нужно)

 

[fixxxer]

REST это высокоуровневая абстракция. Как ты будешь обозначать операции с БД ты должен придумать сам.

А для "понимания" REST ничего не нужно - у тебя все уже есть в $_SERVER, $_GET и $_POST.
Ну один реврайт еще написать, да.

 

[Silentland]

Зачем реврайт? $_PUT $_DELETE есть? А парсить url надо? Сравнивать с чем-то элементы url надо? swith, наверное там будет (сейчас так делаю). Конечно проблем нет, но получится у меня по-китайски. Хотелось бы хотя бы отлаженный пример, как это делается...

 

[fixxxer]

$_GET и $_POST не имеют несмотря на названия никакого отношения к http-методам GET и POST.

REST завязан на использование HTTP-методов, тебе надо для начала разобраться в устройстве протокола HTTP с такими вопросами

 

[Silentland]

$_GET и $_POST не имеют несмотря на названия никакого отношения к http-методам GET и POST.

Как так не имеют? А косвенное? )

$_PUT предлагается сделать так:

$_PUT = array(); 
if($_SERVER['REQUEST_METHOD'] == 'PUT') { 
  $putdata = file_get_contents('php://input'); 
  $exploded = explode('&', $putdata);  
 
  foreach($exploded as $pair) { 
    $item = explode('=', $pair); 
    if(count($item) == 2) { 
      $_PUT[urldecode($item[0])] = urldecode($item[1]); 
    } 
  } 
}

Такой же костыль будет на $_DELETE. Еще велосипед на парсинг url. Должна же быть PHP-библиотека, где все это собрано вместе. Для кучи других языков нашел, для PHP нет

 

[WMix]

зачем тебе делить еще на 2 переменные?, смысл обработать правильно данные (на delete иначе чем на get)
<form action="?id=42" method="post"> создает одним запросом и гет и пост, и это удобно разделять
а зачем тебе $_PUT иметь не понимаю!

подгляди сюда, а то и вправду костылей наделаешь.
https://github.com/codeguy/Slim/blob/master/Slim/Http/Request.php

/**
* Fetch PUT data (alias for \Slim\Http\Request::post)
* @param string $key
* @return array|mixed|null
*/
    public function put($key = null)
    {
        return $this->post($key);
    }

/**
* Fetch DELETE data (alias for \Slim\Http\Request::post)
* @param string $key
* @return array|mixed|null
*/
    public function delete($key = null)
    {
        return $this->post($key);
    }

 

[Silentland]

зачем тебе делить еще на 2 переменные?

Думаю незачем, но тут http://habrahabr.ru/post/46032/ зачем-то приводится пример.

Еще нашел тут реализацию рест-сервера: https://github.com/jacwright/RestServer/blob/master/RestServer.php

И еще тут самый понятный вариант: https://github.com/lexxpavlov/angular-admin/blob/master/app/back/index.php

Ну и вышепредложенный https://github.com/codeguy/Slim/blob/master/Slim/Http/Request.php начну изучать.

Остается выделить лучшее решение

 

[fixxxer]

Silentland
Ну разберись все-таки, откуда берутся $_GET и $_POST. Подсказки:
1) _GET наполняется так (всегда!): parse_str($_SERVER['QUERY_STRING'], $_GET);
2) наполнение _POST делается из тела (того самого php://input) и зависит от отправляемого клиентом content-type. Кстати, процитированный тобой говнокод про _PUT заменяется вызовом parse_str - но что тот говнокод, что parse_str делают предположения относительно content_type, а вообще-то там может быть что угодно

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

 

[Silentland]

Не знаю, я теперь вместо этих массивов $_REQUEST использую, чтобы не привязываться к типу запроса. Да и откуда что берется вполне представляю. Есть запрос стандартного вида у него есть куча полей с данными. Одно из таких полей это тип запроса, другое, УРЛ, третье ПОСТ-данные и еще чет знает что. Какую-то часть обозвали заголовком, какую-то телом. Создатели ПХП решили, что в $_GET будут хранить параметры из URL, в $_POST данные из тела, в $_FILES данные из тела, если там файл. Дурацкая система, но какая есть. А потом пришли другие чуваки и сказали что GET это чтение DELETE удаление и т. д. А в url содержится адрес ресурса.

Честно, не знаю, зачем в примере выделен $_PUT, возможно так удобнее работать с данными...

 

[fixxxer]

А зачем передавать данные в put urlencoded-телом, как при post? При put обычно в теле содержимое файла/сущности.

Вообще, когда HTTP только разрабатывался, предполагалось, что браузеры будут уметь редактировать содержимое и уметь его сохранять (да, глобальная википедия!), и самый первый браузер именно так и работал. И вот это как раз и делал метод PUT - в теле отправлялся отредактированный html-документ, а сервер записывал содержимое поверх старого файла.

 

[Silentland]

Отличный способ в мире, созданном из оптоволокна)) Знал лишь, что посредством PUT можно файлы передавать в ПХП и это типа проще. Но особой выгоды не ощутил... Ну а на деле, какой толк от всех этих массивов, если есть $_REQUEST, а тип запроса можно и так узнать?

 

[WMix]

fixxxer
если чесно, я put вижу больше похожим на post а вот delete на get

PUT /user/123 HTTP/1.1
Host: example.org
...
user-name=mike&hat-size=small

DELETE /users/123 HTTP/1.1
Host: www.example.org
If-Match: "q1w2e3r4t5"

 

[fixxxer]

Я не втыкаю, зачем тут PUT, а не POST, это уже доведение "семантичности" до маразма

 

[WMix]

Фундаментальное различие методов POST и PUT заключается в понимании предназначений URI ресурсов. Метод POST предполагает, что по указанному URI будет производиться обработка передаваемого клиентом содержимого. Используя PUT, клиент предполагает, что загружаемое содержимое соответствует находящемуся по данному URI ресурсу.

Сообщения ответов сервера на метод PUT не кэшируются.


http://ru.wikipedia.org/wiki/HTTP

 

[fixxxer]

Так и я про то =)

PUT /user/1234/avatar.jpg это понятно, тут я согласный.

PUT /user/1234/ - ну есть же обработка.

 

[Absinthe]

Я отказался от PUT т.к. API из PHP используются часто, а через curl передать PUT с телом без костылей нельзя. Поэтому пользоваться им будет не удобно.
В сторону POST /resource/:id/update от PUT /resource/:id отошел.

 

[Silentland]

PUT /user/1234/avatar.jpg это понятно

Писать в ресурсе ссылку непосредственно на файл это нормально?

 

[beckerman]

Попробуй этот фреймворк: http://peej.github.io/tonic/. Он немного мощнее, чем Slim, но тем не менее довольно компактный и почти не глючит. Ресурсы представлены в виде классов и их легко тестировать. Довольно неплохая комбинация с Doctrine.