REST страсти по 200

Давно я хотел написать эту статью. Все думал — с какой стороны зайти правильнее? Но, вдруг, недавно, на Хабре появилась подобная статья, которая вызвала бурю в стакане. Больше всего меня удивил тот факт, что статью начали вбивать в минуса, хотя она даже не декларировала что-то, а скорее поднимала вопрос об использовании кодов ответа web-сервера в REST. Дебаты разгорелись жаркие. А апофеозом стало то, что статья ушла в черновики… килобайты комментариев, мнений и т. д. просто исчезли. Многие стали кармо-жертвами, считай, ни за что

В общем, именно судьба той статьи побудила меня написать эту. И я очень надеюсь, что она будет полезна и прояснит многое.

Предупреждаю, все ниже написанное является реальным опытом, а не когнитивной эквилибристикой. И так, погнали.

Первым делом нужно очень четко разделить слои. Слой транспорта — http. Ну и собственно REST. Это фундаментально важная вещь в принятии всего и “себя” в нем. Давайте сначала поговорим только о http.

Я использовал термин “слой транспорта”. И я не оговорился. Все дело в том, что сам http реализует функции транспортировки запросов к серверу и контента к клиенту независимо от tcp/ip. Да, он базируется на tcp/ip. И вроде, нужно считать именно его транспортным. Но, нет. И вот почему — сокет-соединения не являются прямыми, т. е. это не соединение клиент-сервер. Как http запрос, так и http ответ могут пройти длинный путь через уйму сервисов. Могут быть агрегированы или напротив декомпозированы. Могут кэшироваться, могут модифицироваться.

Т. е. у http запроса как и http ответа есть свой маршрут. И он не зависит ни от конечного бэка, ни от конечного фронта. Прошу на это обратить особое внимание.

Маршруты http не являются статическими. Они могут быть очень сложными. Например, если в инфраструктуру встроен балансировщик, полученные запросы он может отправить на любую из нод бэка. При этом, сам бэк может реализовывать собственную стратегию работы с запросами. Часть из них пойдет на микросервисы напрямую, часть будет обработана самим web-сервером, часть дополнена и передана кому-то еще, а часть выдана из кэша и т. п. Так работает Интернет. Ничего нового.

И тут важно понять — зачем нам коды ответов? Все дело в том, что вся вышеописанная модель принимает решения на их базе. Т. е. это коды, позволяющие принимать инфраструктурные и транспортные решения в ходе маршрутизации http.

К примеру, если балансировщик встретится с кодом ответа от бэка 503, при передаче запроса, он может принять это за основание считать, что нода временно недоступна. Отмечу, что в ответе с кодом 503 предусмотрен заголовок Retry-After. Получив из заголовка интервал для повторного опроса, балансировщик оставит ноду в покое на указанный срок и будет работать с доступными. Причем, подобные стратегии реализуются “из коробки” web-серверами.

Небольшой офтопик для глубины понимания — а если нода ответила 500? Что должен сделать балансировщик? Переключать на другую? И многие ответят — конечно, все 5xx основание для отключение ноды. И будут неправы. Код 500 это код неожиданной ошибки. Т. е. той, которая может больше никогда и не повториться. И главное, что переключение на другую ноду может ничего и не изменить. Т. е. мы просто отключаем ноды без малейшей пользы.

В случае с 500 нам на помощь приходит статистика. Локальный WEB-сервер ноды, может переводить саму ноду в статус недоступности при большом количестве ответов 500. В этом случае, балансировщик обратившись на эту ноду, получит ответ 503 и не будет ее трогать. Результат тотже, но теперь, такое решение осмысленно и исключает “ложные” срабатывания.

Но и это еще не все. В такой ситуации мониторинг позволит админам подключиться к ситуации для обслуживания ноды. Т. е. мы получаем не просто реализацию высокодоступного сервиса, с балансировками и т. п., но еще и эффективный процесс поддержки.

И все это позволяют делать коды ответа сервера. Любая архитектура WEB-приложения должна начинаться с проектирования транспортного слоя. Надеюсь, сомнений в этом не осталось.

Задам риторический вопрос — что это такое? И что вы ответили себе на него? Не буду давать ссылки на очевидные пруфы, но скорее всего не совсем то, чем он является по сути Это лишь идеология, стиль. Некие соображения на тему — как лучше общаться с бэком. И не просто общаться, а общаться в WEB инфраструктуре. Т. е. на базе http. Со всеми теми “полезными штуками”, о которых я написал выше. Конечные решения по реализации вашего интерфейса остаются всегда за вами.

Вы задумывались почему не придуман отдельный транспорт для REST? Например, для websocket он есть. Да, он тоже начинается с http, но потом, после установки соединения, это вообще отдельная песня. Почему бы не сделать такую же для REST?

Ответ прост — а зачем? Есть прекрасный, уже готовый, выверенный протокол — http. Он хорошо масштабируется. Позволяет реализовывать сложные, высокодоступные сервисы, способные справляться с большой нагрузкой. Все, что нужно — ввести некие концептуальные правила, чтобы разработчики друг друга понимали.

Отсюда следует простой, очевидный вывод — все, что присуще http, присуще и REST. Это неотделимые сущности. Нет отдельного заголовка REST, нет даже намека на то, что REST это REST. Для любого сервера REST запрос ровно такой же, как и любой другой. Т. е. REST это только то, что у нас “в голове”.

Коды ответа http в REST

Давайте поговорим о том, каким же кодом должен отвечать ваш сервер на REST запрос? Лично мне кажется, что из всего выше написанного уже очевиден ответ, что т. к. REST не отличается от любого другого запроса, он должен быть подчинен ровно тем же правилам. Код ответа — неотъемлемая часть REST и он должен быть релевантен сути ответа. Т. е. если не найден объект по запросу, это 404, если клиент обратился с некорректным запросом 400 и т. д. Но, чаще всего, дебаты на сём не заканчиваются. Поэтому, продолжу и я.

Можно ли отвечать на всё кодом 200? А кто вам запретит? Пожалуйста… код 200 такой же код как и другие. Правда, в основе такого подхода лежит очень простой тезис — моя система идеальная, у нее не бывает ошибок. Если вы человек, который может создавать такие системы — этому можно только позавидовать!

Но скорее всего… она не идеальна. И ошибки все же случаются. А бывает, что они случаются по независящим от нас обстоятельствам. И тут типовым решением является создание собственной системы кодирования ошибок. Это плохо? Да, это плохо. Это супер-плохо. Давайте разбираться почему.

И так, принимая код 200 как единственно верный, мы берем на себя обязанности на разработку целого слоя (критического слоя) системы — обработку ошибок. Т. е. труд многих людей по разработке этого слоя отправляется в утиль. И начинается постройка своего “велосипеда”. Но эта мегастройка обречена на провал.

Начнем с кода. Если мы собираемся на все отвечать 200, нам самим придется обрабатывать ошибки. Классическим методом является try конструкции. Каждый сегмент кода мы оборачиваем дополнительным кодом. Обработчиками, которые что-то делают полезное. Например, что-то кладут в лог. Что-то важное. Что позволит локализовать ошибку. А если ошибка возникла не там где ее ожидали? Или если ошибка возникла в обработчике ошибки? Т. е. эта стратегия на уровне кода нерабочая априори. И в конце концов, обрабатывать ваши баги будет интерпретатор или платформа. ОС, наконец. Суть бага в том, что вы его не ждете. Не нужно его прятать, его нужно находить и фиксить. Поэтому, если на какие-то запросы REST ответит ошибкой 500 это нормально. И более того — правильно.

Давайте еще раз вернемся к вопросу — почему это правильно? Потому что:

7. Даже если вы очень сильно постараетесь избежать иных кодов ответа от сервера кроме как 200 на ваши запросы, вы не сможете это сделать. Вам может ответить на ваш запрос любой сервер посредник, совершенно любым кодом. И вы ДОЛЖНЫ будете такой ответ обработать корректно.

Итого, на логическом уровне борьба за код 200 бессмысленна.

Теперь давайте вернемся к инфраструктурному уровню. Очень часто слышу мнение — код 5xx не прикладного уровня, его нельзя отдавать бэком. Кхм, ну… тут есть противоречие в самом утверждении. Отдавать можно. Но код этот не прикладного уровня. Вот так вернее. Для понимания этого, предлагаю рассмотреть кейс:

И так, что вы должны ответить? Кому? Это проблема именно инфраструктурная и, именно, бэк столкнулся с ней. Конечно, нужно смело отвечать 503. Эти действия приведут к тому, что нода будет отключена балансировщиком на какое-то время. При этом, балансировщик при правильной настройке, не разрывая соединение с клиентом, отправит запрос в другую ноду. И… конечный клиент, с великой долей вероятности получил 200. А не кастомное описание ошибки, которая ему ничем не поможет.

Где и какой код использовать

Вопрос непростой. На него нет однозначного ответа. Для каждой системы проектируется транспортный слой и коды в нем могут быть специфичные.

Есть принятые стандарты. Их можно легко найти и, опять же, не буду очевидные пруфы приводить. Но, приведу неочевидный — developer. mozilla. org/ru/docs/Web/HTTP/Status
Почему его? Все дело в том, что обработчики кода могут вести себя по разному, в зависимости от реализации и контекста “понимания кода”. К примеру, в браузерах есть стратегия кеширования, завязанная на коды ответа. А в некоторых сервисах есть свои, кастомные коды. Например, CloudFlare.

Т. е. принятие решений об использовании кодов, нужно базировать на всех элементах входящих в транспортный слой от вашего кода на бэке до кода на клиенте. Только так можно найти верные ответы. Я даже пытаться тут дать всем универсальную пилюлю не буду.

Корни зла

Уже третий проект, в который я прихожу страдает кодом 200 в REST. Именно страдает. Другого слова нет. Если вы внимательно прочли всё до текущего момента, вы уже понимаете, что как только проект начинает расти, у него появляется потребность в развитии инфраструктуры, в ее устойчивости. Код 200 убивает все эти потуги на корню. И первое, что приходится делать — ломать стереотипы.

Корень зла, мне кажется лежит в том, что код 500, это первое, что web-разработчик встречает в своей профессиональной деятельности. Это, можно сказать, детская травма. И все его старания поначалу сводятся к тому, чтобы получить код 200.

Кстати, по какой-то причине, на этом же этапе развивается устойчивое мнение, что только ответы с кодом 200 могут быть снабжены телом. Конечно, это не так и с любым кодом может “приехать” любой ответ. Код это код. Тело это тело.

Далее, с развитием разработчика, у него возникают потребности в управлении багами собственного приложения. Но…, он не умеет пользоваться логами. Не умеет настраивать web-сервер. Он учится. И рождаются те самые «велики». Потому что, они ему доступны и он может их быстро сделать. Далее, на этот «велик» он монтирует новые колеса, усиливает раму и т. д. И этот велик становится его спутником на достаточно длительный промежуток времени, пока… пока у него не появляются реально сложные, многокомпонентные задачи. И тут, как говорится — вход в супермаркет с «великами» и на роликах запрещен.

Как исправить ошибку 500

Страницу с кодом ответа 500 веб-сервер возвращает, когда не может обработать запрос из-за ошибок в файлах сайта.

Внешний вид ошибки 500 зависит от того, чем она вызвана. При неполадках в скриптах сайта отобразится пустая страница, сообщение HTTP ERROR 500 или текст обработчика PHP.

Часто ошибку 500 можно легко устранить даже не имея знаний в области веб-разработки. О том, как это сделать, расскажем далее.

Ошибки в скриптах сайта

Пустая страница — не всегда признак ошибки 500. Поэтому в первую очередь узнайте код ответа, с которым она открывается. Это можно сделать при помощи инструментов разработчика в браузерах.

Инструменты разработчика — функция для исследования работы сайта. Она позволяет узнать время ответа сервера, код ответа, посмотреть текст возникших ошибок и многое другое.

Нажмите сочетание клавиш Ctrl+Shift+I или используйте меню браузера:

Перейдите во вкладку «Сеть (Network)». На ошибку 500 указывает соответствующее число в колонке «Статус».

Статус пустой страницы может быть и 200 (Ok). В таком случае проверьте, есть ли содержимое в индексном файле сайта, очистите кеш вашей CMS. Если ранее сайт работал корректно, восстановите его из резервной копии.

Вывод ошибок на сайте

Если текст не отобразился, включите вывод ошибок через конфигурационный файл CMS. Он расположен в корневой директории сайта.

WordPress

Замените в файле wp-config. php строку define(‘WP_DEBUG’, false); на define(‘WP_DEBUG’, true);

Joomla

1С-Битрикс

В конфигурационном файле по пути

Laravel

Алгоритм устранения ошибки можно найти в интернете, поместив ее текст в строку любой поисковой системы. Если с помощью найденной информации возобновить работу сайта не получится, восстановите его из резервной копии. Наши специалисты могут помочь с восстановлением. Для этого направьте обращение из раздела «Поддержка» Панели управления.

Журнал ошибок PHP

Откройте создавшийся файл журнала с помощью Файлового менеджера в Панели управления. Чтобы просматривать возникающие ошибки в реальном времени, отметьте опцию «Включить автообновление».

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

Для устранения некоторых ошибок не требуется специальных знаний. Рассмотрим самые распространенные.

Нехватка оперативной памяти

Ошибка с текстом Allowed memory size возникает из-за нехватки оперативной памяти для выполнения скрипта: PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 81 bytes) in /home/username/domains/domain. ru/public_html/somescript. php

php_value memory_limit 512M

Вместо «512» укажите необходимый объем памяти. Максимальное значение ограничивается тарифом.

Текст Out of memory означает, что достигнут лимит оперативной памяти по тарифному плану:

PHP Fatal error: Out of memory (allocated 39059456) (tried to allocate 262144 bytes) in /home/username/domains/domain. ru/public_html/somescript. php

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

Ошибки в CMS

При обновлении CMS случаются синтаксические ошибки:

PHP Parse error: syntax error, unexpected ‘[‘, expecting ‘)’ in /home/username/domains/domain. ru/public_html/wp-content/plugins/wordpress-23-related-posts-plugin/config. php on line 130

Это происходит из-за того, что новые функции CMS не поддерживают устаревшие версии PHP. Чтобы исправить ошибку, измените версию PHP для сайта на более современную в разделе «Сайты и домены» → «Управление сайтами».

Если предыдущая рекомендация не помогла, обратите внимание на путь до неработающего скрипта: там может быть указан каталог плагина или темы. Чтобы исправить ошибку, отключите их. Для этого переименуйте папку, в которой они расположены. После устранения ошибки авторизуйтесь в административной части сайта и измените тему или переустановите плагин.

Чтобы исправить большинство ошибок PHP, достаточно изучить их текст и принять меры, указанные в статье. Если вам не удается справиться с ней самостоятельно, обратитесь в службу поддержки.