Comments 6
Картинка на заставке зачётная, вот только это абсолютно нормальное состояние наборных регулирующих плотин.
Понимаю, что это перевод, но все же.
Content-Type: application/x-www-form-urlencoded; charset=iso-8859-1Если сервер предполагает, что используется UTF-8, то он декодирует закодированные процентами байты, как UTF-8 и сохраняет их. Повреждение необратимо.
Если в запросе передана кодировка charset, то парсеры запроса будут использовать ее при URLDecode. Это касается как Tomcat / Jetty / Netty, так и оберток на уровне Spring. Иное поведение, где не учитывается кодировка из заголовка Content-Type и используется кодировка по умолчанию, - это просто баг.
Method Not Allowed должен сообщать, что подходит
Кстати покритикуйте
Я проектирую API и вывел для себя правило: сообщение об ошибке должно содержать рекомендацию по ее устранению.
Например было так:
{
“code”: 400,
“message”: “Ошибка 400"
}
А стало так
{
“code”: 400,
“message”: “Допустимые символы: % . : _ -”
"data": <тут исходный текст запроса>
}
Конечно это требует некоторой возни в начале, но впоследствии экономит массу времени для клиентов и саппорта. Например в одной организации (финтех между прочим) путем перелопачивания всех сообщений об ошибках приложения колво обращений в саппорт от интегрирующихся клиентов снизилось на ≈80%.
Среди оставшихся обращений образовался явный лидер с большим отрывом, но это может звучать оскорбительно для определенной категории прогеров, поэтому разрешите не приводить его ;)
До разработчиков API начинает доходить то, что веб-разработчики делали ещё 20 лет назад
А что тут критиковать, так и должно быть. В Rails, например, ошибки так и отображаются по умолчанию.
Одно не понятно - для чего исходный запрос обратно отправлять?
Ни в одном даже самом модном-волшебном фреймворке не будет отображаться то, что не было написано. Вы же понимаете что пример с регуляркой — наиболее простой случай "для примера" и в API порой встречается более сложная логика.
Проконтролировать, не протухло ли чего по дороге. Мне не жалко, а клиент сравнит что он отправлял и что фактически прилетело.
Пограничные случаи HTTP, которые должен понимать каждый разработчик API