Также надо помнить, что многих трудящихся отсутствие СИДН не коснется – к примеру лиц, которые работают удаленно на российские компании, так как согласно принятым неделю назад поправкам в НК РФ их ставка НДФЛ зафиксирована на уровне 13–15% вне зависимости от статуса резидента.
С точки зрения уплаты НДФЛ в РФ понятно. Но что на счет его зачета в "недружественной" стране где работник является налоговым резидентом и тоже должен платить налог с этих доходов?
Аннотации типов — нужны для документации и плюшек в IDE, а не для типизации. Никто из разработчиков языка внедрить в него типизацию не пытается.
По-моему, все как раз наоборот. В первую очередь это статический анализ, а уже потом автокомплит. Гвидо не просто так пилил mypy в дропбоксе. Другие крупные компании тоже пилят тайп-чекеры: pyre (Facebook), pyright (Microsoft), pytype (Google). Активное развитие стандартного модуля typing во многом связано с issues, которые заводились для mypy. Ну и вообще если писать тайп-хинты и не использовать тайп-чекер, то такие тайп-хинты постоянно будут в невалидном/неактуально состоянии
Прочитайте пожалуйста мою статью habr.com/ru/post/440900 в части «Коды ответа http в REST» там я популярно изложил все стадии «принятие» REST.
Прочитал. 404 упоминается ровно один раз:
Т.е. если не найден объект по запросу, это 404
Утверждение без какой-либо аргументации.
Если говорить про статью, я согласен, например, с доводами про использование http 500 и что вообще хорошо бы уже по статусу отличать состояние, когда все прошло успешно (2xx) от неуспешного (>=400, что с этим дальше делать клиенту уже другой вопрос). Но у меня есть претензия конкретно к использованию 404.
Идемпотентность в контексте http не означает что response status должен быть одинаковый, а говорит только о том, что при повторных запросах не должно появлять дополнительных сайд-эффектов на стороне сервера.
Ну не надо передергивать. Вы прекрасно поняли что я имел в виду: например, сломали роутинг. По существу можете что-нибудь ответить? Что делать с неконсистентностью в случае когда она неприемлема?
Ну вот мы, ожидаемо, и пришли к тому, что одних http-статусов не достаточно и нужно отправлять дополнительные данные в body/headers и в клиенте опираться на них
Да собственно не важно БД или не БД. У нас есть ресурс с определенным URI и мы хотим проверить существование этого ресурса. Если мы получаем ложноотрицательный ответ (в случае когда 404 вернулся из-за недоступности сервиса) о существовании этого ресурса, то это неконсистентное состояние системы. В каких-то случаях такая неконсистентность допустима, в каких-то — нет
то вы просто преборазуете 404 в 500. Зачем-то… хотя суть ошибок разная. И главное, приравнивает (sic!) 404 к 500
Ну как раз приравнивание ошибок происходит в вашем случае. Недоступность какого-то апи приравнивается к нормальному ответу. Это равносильно приравниванию пустого ответа от субд к отсутствию коннекта к этой субд
Это как? Роут перепутан… ничего до бэка не дошло. Просто 404. Что в этом случае?
500тить будет клиент этого endpoint'а, получивший 404. Это нештатная ситуация, в которой клиент не может продолжить работать не получив эти данные.
Не в коем разе. Это плохая практика. Ибо вашу поддержку могут просто затроллить. Она сума сойдет разгребая запросы.
Вы сейчас имеете в виду запросы, которые приходят снаружи (браузер и т.д.)? Я же имел в виду в первую очередь взаимодействие между внутренними сервисами, где никто никого троллить не станет
Может. Но это не значит, что он будет сломан постянно. Через установленный промежуток времени, мониторинг покажет ошибку.
В таком случае мониторинг будет носить вероятностный характер. Т.е. нужны еще какие-то сложные правила, что от определенного endpoint'а должен быть какой-то процент не-404 ответов
С точки зрения уплаты НДФЛ в РФ понятно. Но что на счет его зачета в "недружественной" стране где работник является налоговым резидентом и тоже должен платить налог с этих доходов?
По-моему, все как раз наоборот. В первую очередь это статический анализ, а уже потом автокомплит. Гвидо не просто так пилил mypy в дропбоксе. Другие крупные компании тоже пилят тайп-чекеры: pyre (Facebook), pyright (Microsoft), pytype (Google). Активное развитие стандартного модуля typing во многом связано с issues, которые заводились для mypy. Ну и вообще если писать тайп-хинты и не использовать тайп-чекер, то такие тайп-хинты постоянно будут в невалидном/неактуально состоянии
А как же mypy?
Я вообще ничего про nginx не писал.
Понятно. Все ваши аргументы против приведенных доводов сводятся к безапелляционным утверждениям в стиле и .
навскидку:
user/[0-9]{2})/user/42/ работает нормально user/666/ всегда возвращает 404Прочитал. 404 упоминается ровно один раз:
Утверждение без какой-либо аргументации.
Если говорить про статью, я согласен, например, с доводами про использование http 500 и что вообще хорошо бы уже по статусу отличать состояние, когда все прошло успешно (2xx) от неуспешного (>=400, что с этим дальше делать клиенту уже другой вопрос). Но у меня есть претензия конкретно к использованию 404.
Ну не надо передергивать. Вы прекрасно поняли что я имел в виду: например, сломали роутинг. По существу можете что-нибудь ответить? Что делать с неконсистентностью в случае когда она неприемлема?
согласен
Вот и мне не понятно
Ну так я как раз об этом и писал, что в этом кейсе опираться только на статус 404 довольно опасно.
Да собственно не важно БД или не БД. У нас есть ресурс с определенным URI и мы хотим проверить существование этого ресурса. Если мы получаем ложноотрицательный ответ (в случае когда 404 вернулся из-за недоступности сервиса) о существовании этого ресурса, то это неконсистентное состояние системы. В каких-то случаях такая неконсистентность допустима, в каких-то — нет
уверенность никак не говорит о вашей правоте или неправоте. У кого-то может уверенность в противоположных вещах.
К слову, у вас в профиле никаких проектов нет. По крайней мере, для меня они не видны
Это аргумент в стиле вы тут все неопытные юнцы, один я знаю как правильно делать? Или мне показалось?
Ну как раз приравнивание ошибок происходит в вашем случае. Недоступность какого-то апи приравнивается к нормальному ответу. Это равносильно приравниванию пустого ответа от субд к отсутствию коннекта к этой субд
en.wikipedia.org/wiki/Web_API#Endpoints
Наконец-то мы поняли друг друга
Можете развернуть мысль. Я не очень понял что тут имеется в виду.
При чем тут создание, если речь шла о получении объекта? И при чем здесь база?
500тить будет клиент этого endpoint'а, получивший 404. Это нештатная ситуация, в которой клиент не может продолжить работать не получив эти данные.
Вы сейчас имеете в виду запросы, которые приходят снаружи (браузер и т.д.)? Я же имел в виду в первую очередь взаимодействие между внутренними сервисами, где никто никого троллить не станет
В таком случае мониторинг будет носить вероятностный характер. Т.е. нужны еще какие-то сложные правила, что от определенного endpoint'а должен быть какой-то процент не-404 ответов