Не хочу никого обидеть, но это пример обычного говнокоддинга. Человее не знает про безопасные запросы, не умеет работать с xPDO, зачем-то выставляет плейсхолхолдеры, хотя метод getChunk вторым параметром принимает массив плейсхолдеров. Видимо начинающий. Тут переделать дело 10 минут. Думаю, найдётся кто-нибудь свободный.
Обрати внимание на метод $app->run();
В нём вызываются конкретные классы. Причем, если не указан конкретный реквест, то он определяется автоматически по установленным пакетам (я выше писал).
Но признаюсь, синтаксис в slim4 мне сложноват, он прям на полную использует все нововведения седьмых версий php
А мне безумно нравится. В пекло PHP 5. ))
Я на данном этапе решил, что методы из интерфейса psr-7 (и psr-15 ) вшиты в сам php.
В комментарии это не обьяснишь. Попробуй почитать тут. Но ты как-то широко шагнул. Сначала нужно базовые знания получить, а потом усложнять.
Интерфейсы дают малую связанность. Т.е. ты можешь подсунуть в метод любой класс, соответствующий определенным требованиям. За это как раз и отвечает интерфейс.
Но где прописана реализация этих методов из стандарта psr-7?
У того же Slim эти классы пробрасываются при инициализации приложения. В нем жестко прописана проверка наличия нескольких пакетов. Сначала свой пакет, потом Guzzle и ещё какие то. Не помню. Но можно и самому инстанциировать любой свой класс запроса или ответа. Главное, чтобы соответствовал интерфейсу. Иначе будет ошибка.
Есть фреймворки. строго следующие этим стандартам. К примеру Slim.
Тройка ещё не соответствует. Например, $response->toJson() не соответствует стандарту. А вот четверка поддерживает почти все текущие утвержденные стандарты. После тройки приходится привыкать. И всякие методы обработки запроса и ответа выносить на сервисный уровень.
Следуя парадигме современной разработки, использовать папку model нужно только для моделей. Т.е. класс модели xPDO, схема и мап-файл. Остальному там не место.
REST — это архитектурный стиль. А RESTful API — это реализация этого стиля.
Правильно говорить именно RESTful API, но в народе уже прижилось неправильное название REST API.
Возможно автор топика дальше раскроет тонкости проверки прав, но в этом топике не сделал акцент, что вот за этим
// Проверяем, что пользователю предоставлены необходимые права доступа;
// Бьем по рукам и Возвращаем пользователю ошибку 401 ежели чего
if (!$rest->checkPermissions()) {
$rest->sendUnauthorized(true);
}
ничего не стоит, хотя комментарий вселяет уверенность, что проверка есть. А если заглянуть в код этого метода, то увидим следующее
public function checkPermissions() {
return true;
}
Никак ни с токен-авторизацией, ни с какой другой. Есть всего один абстрактный контроллер, который нужно наследовать. Поэтому разработчику придётся всё писать самостоятельно.
Не так. Системная настройка отвечает за множественный вывод как и раньше. А вот новая галочка у ресурса позволяет убрать URL этого ресурса из урлов дочерник элементов. Т.е. если если у ресурса parent2 убрать этот чекбокс, то урл дочернего документа c урлом parent1/parent2/child1 он будет такой — parent1/child1.
В таком формате xPDO вставляется без обработки.
П.С, Это json массив с одной строкой.
Обрати внимание на метод $app->run();
В нём вызываются конкретные классы. Причем, если не указан конкретный реквест, то он определяется автоматически по установленным пакетам (я выше писал).
А мне безумно нравится. В пекло PHP 5. ))
Найн. Ю а ронг.
Интерфейсы дают малую связанность. Т.е. ты можешь подсунуть в метод любой класс, соответствующий определенным требованиям. За это как раз и отвечает интерфейс.
У того же Slim эти классы пробрасываются при инициализации приложения. В нем жестко прописана проверка наличия нескольких пакетов. Сначала свой пакет, потом Guzzle и ещё какие то. Не помню. Но можно и самому инстанциировать любой свой класс запроса или ответа. Главное, чтобы соответствовал интерфейсу. Иначе будет ошибка.
Тройка ещё не соответствует. Например, $response->toJson() не соответствует стандарту. А вот четверка поддерживает почти все текущие утвержденные стандарты. После тройки приходится привыкать. И всякие методы обработки запроса и ответа выносить на сервисный уровень.
Не обязательно расширять сервис ради проверки прав. Мы можем сделать любую проверку самостоятельно
Правильно говорить именно RESTful API, но в народе уже прижилось неправильное название REST API.
ничего не стоит, хотя комментарий вселяет уверенность, что проверка есть. А если заглянуть в код этого метода, то увидим следующее
Новички могут попасть.
Попробуй очистить кэш.