Интерфейсы ядра cовременного сайта

К написанию этой статьи меня сподвигла работа над порталом для министерства некой «незалежной» страны. Я выполнял роль сторонего разработчика модулей, поэтому работать пришлось с чужим движком.
По некой причине, система не должна была иметь предшественников, поэтому писалась строго с нуля, включая и концепцию. Вот эта самая концепция и повергла в шок. Точнее её отсутсвие во многих моментах. Проверка доступа? — Сделаем позже, не морочь голову. AJAX? — будет завтра. А лучше делай как тебе удобнее. POST? — Обработай в контролере.
После этого и возникла мысль: «А всё таки, какие интерфейсы, транспорты, должно поддерживать современное ядро сайта?». Здесь я небуду распостранятся о низкоуровневой реализации этих интерфейсов, просто пройдусь по логике работы.

GET

Этот интерфейс позволяет обрабатывать запросы «Из адресной строки». К нему выдвигается 2 требования:

• Отображение содержимого в зависимости от пользователя, запросившего страницу
• Задание произвольных псевдонимов для страниц (Например catalog/shapki/ushanki вместо catalog/1/2)

POST

Данный интерфейс обрабатывает данные переданные POST-запросом (формы, файлы, спец. данные). После чего, управление должно быть переданно обработчику GET запроса, для вывода содержимого страницы.
Требования:

• Независимость от адреса вызываемой страницы (поля action формы). Это необходимо, т.к. некоторые данные могут прийти на любую страницу сайта (скажем авторизация).
• Зависимость метода обработки данных, от пользователя его вызвавшего

AJAX

С точки зрения программиста, я сейчас написал глупость. Т.к. AJAX и является GET/POST запросом. Однако логически, AJAX не является запросом в привычном смысле этого слова вовсе. По большому счёту, пользователь может далеко не всегда понимать, на AJAXе ли работает эта кнопочка, либо просто показывается загруженное ранее. Именно поэтому возникает не технический вопрос обработки AJAX запроса (многие пускают его именно через GET/POST интерфейс), а логически обоснованный фреймворк, позволяющий разработчикам избежать многократных паралельных циклических запросов к сайту, несанкционированных использований AJAX функций; с лёгкостью добавлять новые доступные методы.

Итак, какие у нас есть случаи, когда приходится вызывать AJAX? Собственно, исходя из них, я и распишу интерфейсы AJAX, которые должны присутствовать в уважающем себя(разработчиков) сайте.

По клиентскому событию

Это стандартный случай, когда пользователь, к примеру, нажимает кнопку. Ничего нового тут не добавишь, кроме как напомнить, что AJAX запрос также должен проходить проверку прав.

По таймеру(переодическое)

Интерфейс должен позволять выполнять запросы к сайту через определённый промежуток времени. Необходим именно единый интерфейс, для того, чтобы не плодить множественные циклы (проверка новых писем, новых сообщений, приглашений, напоминаний и тп).

По серверному событию

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

Вот собственно и всё.