Pull to refresh
27
0
LighteR @LighteR

User

Send message

Также надо помнить, что многих трудящихся отсутствие СИДН не коснется – к примеру лиц, которые работают удаленно на российские компании, так как согласно принятым неделю назад поправкам в НК РФ их ставка НДФЛ зафиксирована на уровне 13–15% вне зависимости от статуса резидента.

С точки зрения уплаты НДФЛ в РФ понятно. Но что на счет его зачета в "недружественной" стране где работник является налоговым резидентом и тоже должен платить налог с этих доходов?

Аннотации типов — нужны для документации и плюшек в IDE, а не для типизации. Никто из разработчиков языка внедрить в него типизацию не пытается.

По-моему, все как раз наоборот. В первую очередь это статический анализ, а уже потом автокомплит. Гвидо не просто так пилил mypy в дропбоксе. Другие крупные компании тоже пилят тайп-чекеры: pyre (Facebook), pyright (Microsoft), pytype (Google). Активное развитие стандартного модуля typing во многом связано с issues, которые заводились для mypy. Ну и вообще если писать тайп-хинты и не использовать тайп-чекер, то такие тайп-хинты постоянно будут в невалидном/неактуально состоянии

Type hinting — это чисто поддержка в IDE. То же самое и в докстринге написать можно.

А как же mypy?
Область применения HTTP API не ограничивается только браузерным js'ом
Т.е. с nginx тема не прокатила

Я вообще ничего про nginx не писал.
возмите плз и сами найдите ответы почему эти сценарии надуманы

Понятно. Все ваши аргументы против приведенных доводов сводятся к безапелляционным утверждениям в стиле
Ваш это не нужно
и
такого не бывает
.
Ну не может быть такого примера, понимаете?

навскидку:
  • Service Discovery стал вести не в тот контейнер
  • Ошибка конфигурации API Gateway
  • В коде сервиса сделали ошибку, что привело к изменению (или вообще удалению) url'а, и соответсвенно запрос на него всегда возвращает 404
  • Ошибка в роутах с regexp'ами типа user/[0-9]{2})/ user/42/ работает нормально user/666/ всегда возвращает 404
Прочитайте пожалуйста мою статью habr.com/ru/post/440900 в части «Коды ответа http в REST» там я популярно изложил все стадии «принятие» REST.

Прочитал. 404 упоминается ровно один раз:
Т.е. если не найден объект по запросу, это 404

Утверждение без какой-либо аргументации.
Если говорить про статью, я согласен, например, с доводами про использование http 500 и что вообще хорошо бы уже по статусу отличать состояние, когда все прошло успешно (2xx) от неуспешного (>=400, что с этим дальше делать клиенту уже другой вопрос). Но у меня есть претензия конкретно к использованию 404.
Если отказаться от идеи использовать 404 как нормальный ответ от api это же решит проблему, которую мы обсуждаем?
Идемпотентность в контексте http не означает что response status должен быть одинаковый, а говорит только о том, что при повторных запросах не должно появлять дополнительных сайд-эффектов на стороне сервера.
Недоступность сервиса — 503.

Ну не надо передергивать. Вы прекрасно поняли что я имел в виду: например, сломали роутинг. По существу можете что-нибудь ответить? Что делать с неконсистентностью в случае когда она неприемлема?
Золотое правило — вообще на него не опираться, и не будет проблем.

согласен
Если все палки ломаются вокруг этого, непонятно почему.

Вот и мне не понятно
Не очень удачный пример. В этом случае надо вернуть пустую коллекцию или null

Ну так я как раз об этом и писал, что в этом кейсе опираться только на статус 404 довольно опасно.
Ну вот мы, ожидаемо, и пришли к тому, что одних http-статусов не достаточно и нужно отправлять дополнительные данные в body/headers и в клиенте опираться на них
REST не БД, даже если ответ берется из БД

Да собственно не важно БД или не БД. У нас есть ресурс с определенным URI и мы хотим проверить существование этого ресурса. Если мы получаем ложноотрицательный ответ (в случае когда 404 вернулся из-за недоступности сервиса) о существовании этого ресурса, то это неконсистентное состояние системы. В каких-то случаях такая неконсистентность допустима, в каких-то — нет
я могу быть уверенным в том, что я говорю

уверенность никак не говорит о вашей правоте или неправоте. У кого-то может уверенность в противоположных вещах.
Один из моих проектов в профиле.

К слову, у вас в профиле никаких проектов нет. По крайней мере, для меня они не видны

Когда будете создавать внешний сервис, когда дойдете до того, о чем я вам пишу, плз, если не сложно черканите, если я окажусь не прав ;)

Это аргумент в стиле вы тут все неопытные юнцы, один я знаю как правильно делать? Или мне показалось?
то вы просто преборазуете 404 в 500. Зачем-то… хотя суть ошибок разная. И главное, приравнивает (sic!) 404 к 500

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

en.wikipedia.org/wiki/Web_API#Endpoints
Если речь идет о внутренних сервисах и клиентах, то да, 404 вполне резонно стоит контролировать. Тогда в этом есть смысл.

Наконец-то мы поняли друг друга
Все логика на существование элемента может только подсказывать валидации

Можете развернуть мысль. Я не очень понял что тут имеется в виду.
ибо при создании последнее слово все равно скажет база, смогла ли она создать или нет.

При чем тут создание, если речь шла о получении объекта? И при чем здесь база?
Это как? Роут перепутан… ничего до бэка не дошло. Просто 404. Что в этом случае?

500тить будет клиент этого endpoint'а, получивший 404. Это нештатная ситуация, в которой клиент не может продолжить работать не получив эти данные.
Не в коем разе. Это плохая практика. Ибо вашу поддержку могут просто затроллить. Она сума сойдет разгребая запросы.

Вы сейчас имеете в виду запросы, которые приходят снаружи (браузер и т.д.)? Я же имел в виду в первую очередь взаимодействие между внутренними сервисами, где никто никого троллить не станет
Может. Но это не значит, что он будет сломан постянно. Через установленный промежуток времени, мониторинг покажет ошибку.

В таком случае мониторинг будет носить вероятностный характер. Т.е. нужны еще какие-то сложные правила, что от определенного endpoint'а должен быть какой-то процент не-404 ответов
1
23 ...

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Registered
Activity