Мысли о том, как приложение должно работать с запросами
17/05/2009 23:53
PHP скрипт может быть запущен из-под:
- Веб-сервера
- Коммандной строки (CLI)
- PHP-GTK (GUI интерфейс на php) (не знаю, как технически оно там работает)
Движок должен сам определять, под чем он запущен (Web Server, CLI, PHP-GTK) и, в зависимости от этого, запускать нужный класс (CLI, HTTP_Request, PHP_GTK). Все эти классы наследуются от класса Abstract_Request, который описывает интерфейс объекта запроса (т.е. методы и свойства, которые обязательно должен содержать суперкласс).
К примеру, при работе через коммандную строку в приложение не получает заголовки, оно получает лишь набор переданных приложению параметров. В этом случае, наш класс (CLI) может содержать набор методов для облегчения работы с полученными параметрами. Например:
- Проверить, передан ли некий параметр
- Получить параметр
- Кол-во переданных параметров
- Получить весь список параметров
При работе через HTTP - приложение получает набор заголовков и тело (тело только при запросах типа POST и PUT). И тут уже наш класс HTTP_Request может содержать кучу методов:
- Получить текущий URI
- Получить текущий домен
- Получить текущий IP
- Получить произвольный заголовок
- Текущий метод запроса - POST?
- Текущий метод запроса - GET?
- Текущий метод запроса - PUT?
- Текущий метод запроса - HEAD?
- Текущий метод запроса - OPTIONS?
- Текущий метод запроса - DELETE?
- Получить текущую кодировку
Ну и различные другие методы.
Дальше.
Допустим, мы захотели, чтобы наше приложение научилось понимать AMF запросы, т.е. запросы, приходящие от Flash. Как я понял, в php скрипт такие запросы приходят методом POST, в теле которого содержится сериализованный объект Flash в бинарном виде.
Значит, наша задача сводится к разбору этого объекта. Так же нам понадобится добавить полезные методы для работы с AMF, какие? Пока не знаю. Зависит от того, что мы хотим.
Так как AMF запросы передаются по протоколу HTTP, то мы создадим новый класс HTTP_AMF_Request, унаследованный от HTTP_Request. Надеюсь, понятно почему?
И вот какая дилемма у меня возникла. Начнем с примера.
Допустим, у нас есть некий сайт, который работает по HTTP и, соответственно, движок, понимая это, автоматически использует класс HTTP_Request.
Но вдруг нам понадобилось, чтобы какая-то часть сайта понимала запросы, приходящие с использованием AMF. Значит, нам надо чтобы движок для таких запросов стал подключать HTTP_AMF_Request. Но как это сделать?
Я вижу такие выходы из этой ситуации.
- Всегда пождключать HTTP_AMF_Request, так как он будет работать и для AMF запросов и для обычных HTTP запросов.
- Автоматически определять тип запроса, и если пришел AMF запрос, то использовать HTTP_AMF_Request
- Написать хитрый конфиг, в котором прописать, какие части сайта хотят понимать AMF запросы и подключать для них HTTP_AMF_Request
Пока склоняюсь к использованию 1-го метода. По моему мнению самый тупой способ - это способ 3.
Расскажу, почему считаю способ номер 1 самым лучшим.
Сайт всегда работает с использованием одного протокола - HTTP. Если мы хотим, чтобы какая-то часть сайта умела работать с запросами, основанными на использорвании протокола HTTP, то мы просто могли бы добавить эти специальные возвожности, расширив стандартный класс запроса (HTTP_Request) .
Если я захочу, чтобы сайт мог работать так же по протоколу NNTP, допустим, если захочу, чтобы по NNTP транслировался форум, то мне придется делать отдельное приложение, в котором я создам класс NNTP_Request (унаследованный от Abstract_Request). Этот класс и будет принимать поступившие запросы от NNTP-сервера.
В заключении мысль такая: Одно и то же приложение не может одновременно понимать запросы разных типов (как например HTTP и NNTP). Но если хотим добавить поддержку технологии, работающей на основе какого-либо протокола (как HTTP), то тогда создаем новый класс, унаследованный, в данном случае, от HTTP_Request и, далее, используем этот класс во всем приложении.
Ссылки по теме:
Всегда подключать HTTP_*_Request можно если классов подреквестов не много, иначе второй путь лучше имхо