Работа с API и интеграцией

Если твой API на любой странный запрос отвечает «всё по 200», ты не понимаешь, что пошло не так. Вроде бы интеграция работает, но разработчик на том конце вечно пишет: «А почему у тебя тут 200, а данных нет?» И начинается разбор полётов, который мог бы не начинаться. HTTP-код ошибки - это первое, что видит клиент. И если он врёт, ты сам же потом расплачиваешься за эту ложь. Разберусь с кодами, которые встречаются в каждом API, и объясню, когда что возвращать, чтобы контракт был понятным и предсказуемым...

На совещании заказчик открыл сайт и сказал: «Всё сломалось». Я глянул на цифры в адресной строке. Там был 503. Я улыбнулся: «Это не мы сломали. Это сервер прилёг». Заказчик удивился: «Откуда ты знаешь по двум цифрам?» Вот про это и расскажу. Коды ошибок HTTP — это не набор случайных чисел, а готовая диагностика. Надо лишь научиться их читать. HTTP-код — трёхзначный, и решает первая цифра. Она говорит, на чьей стороне проблема: Главное правило: 4xx — разбирайся у себя, 5xx — жди/зови того, кто держит сервер...

Разбирал интеграцию и открыл контракт. В нём — GET /deleteUser?id=5. Команда с гордостью называла это «REST-ом». Спойлер: REST — это не про красивые URL и не про то, что «тут есть GET и POST». REST — это архитектурный стиль, который определяет, как клиент и сервер общаются через HTTP. Придумал его Рой Филдинг в 2000 году. И понять его проще, чем кажется. Представь склад с полками. На каждой — товар с номером. Плохой «REST» — это когда ты кричишь повару на кухне: «Приготовь-ка пользователя с номером 5!» — то есть вызываешь действие...