Neurons to bytes

Мысли о том, как приложение должно работать с запросами

PHP скрипт может быть запущен из-под:

  1. Веб-сервера
  2. Коммандной строки (CLI)
  3. 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. Но как это сделать?

Я вижу такие выходы из этой ситуации.

  1. Всегда пождключать HTTP_AMF_Request, так как он будет работать и для AMF запросов и для обычных HTTP запросов.
  2. Автоматически определять тип запроса, и если пришел AMF запрос, то использовать HTTP_AMF_Request
  3. Написать хитрый конфиг, в котором прописать, какие части сайта хотят понимать AMF запросы и подключать для них HTTP_AMF_Request

Пока склоняюсь к использованию 1-го метода. По моему мнению самый тупой способ - это способ 3.

Расскажу, почему считаю способ номер 1 самым лучшим.
Сайт всегда работает с использованием одного протокола - HTTP. Если мы хотим, чтобы какая-то часть сайта умела работать с запросами, основанными на использорвании протокола HTTP, то мы просто могли бы добавить эти специальные возвожности, расширив стандартный класс запроса (HTTP_Request) .
Если я захочу, чтобы сайт мог работать так же по протоколу NNTP, допустим, если захочу, чтобы по NNTP транслировался форум, то мне придется делать отдельное приложение, в котором я создам класс NNTP_Request (унаследованный от Abstract_Request). Этот класс и будет принимать поступившие запросы от NNTP-сервера.

В заключении мысль такая: Одно и то же приложение не может одновременно понимать запросы разных типов (как например HTTP и NNTP). Но если хотим добавить поддержку технологии, работающей на основе какого-либо протокола (как HTTP), то тогда создаем новый класс, унаследованный, в данном случае, от HTTP_Request и, далее, используем этот класс во всем приложении.

Ссылки по теме:

Also interesting

  • No Related Post

  1. Homoz says:

    Всегда подключать HTTP_*_Request можно если классов подреквестов не много, иначе второй путь лучше имхо


(required)


(required but won't be displayed)