13 496
правок
Изменения
→Заключение
'''Если стремиться к наиболее «красивому» и логичному интерфейсу, то:'''
Всё, что существует — отстойсуществующее фигня. ) С моей точки зрения, по идеологии наиболее близок к идеалу подход LWP и HTTP::Server::Brick — на входе объект «запрос», на выходе объект «ответ». Однако Но этот подход совсем не очень популярен, поэтому , используя его, вы обрекаете себя на разработку и поддержку своей реализации — никто не говорит, что это плохо, но… не mainstream. Данный подход был выбран личной мной в платформе [[Sway Solstice]]. Исходные коды можно увидеть [http://svn.yourcmc.ru/viewvc.py/vitaphoto/branch/solstice/lib-sway/HTTP/ здесь] — они включают в себя реализацию HTTP::Request::Incoming — подкласса HTTP::Request с некоторыми удобными функциями разбора запроса, и абстракции HTTP::Request для mod_perl 1 и 2, CGI и nginx.
'''Если хочется простоты в стиле PHP, то:'''
'''А если выбирать наиболее универсальный и «mainstream» (широко поддерживаемый) интерфейс, то:'''
Это, конечно же, '''CGI'''. Что и объясняет популярность FastCGI — эквивалентного наиболее простому интерфейсу, обёрнутому в «ускоритель». Если хочется — использовать HTTP::Server::Simple тоже можноможно — он хоть и простой, но только осторожно очень удобный. Отдавать с помощью него же статику я, правда, не стал бы… :).
Также следует помнить о всё ещё очень высокой популярности mod_perl. Ни универсальностью, ни надёжностью от него не пахнет, это нужно понимать, но всё-таки, во-первых, такой гибкости в обработке запросов невозможно добиться больше ни на одной платформе, а во-вторых, поддерживается он достаточно широко и поэтому вполне подходит для использования.
