Судя по System.Diagnostics вы, скорее всего, .NET разработчик. В .NET намного проще работать с REST API на статус кодах и сильно упрощает поддержку и разработку.
Как вы поняли, я тоже работал в нескольких проектах с REST API со статус кодами, так и с REST API на 200 статусе.
Я не говорю что статус коды однозначеное зло. Наоборот. в .NET мире гораздо проще работать с REST API на статус кодах так как и сервер ASP.NET и HttpClient заточены под это. Я всего лишь прошу не утверждать что 200 это всегда неправильно и за это надо кого то стыдить. Иногда гораздо проще делать решения на 200 тых кода как с точки зрения бизнеса так и с точки зрения поддержки легаси инфраструктуры. И обходится это гораздо дешевле чем переделывание легаси.
Но я могу понять вашу точку зрения так как, в отличае от других языков в .Net мире нет такого богатого выбора разных фремворков и клиентов.(точнее альтернативы и выбор есть но их популярность по отношению к базовым на уровне погрешности, так как базовых обычно хватает с лихвой).
Насчет примера с SOAP злоупотребления всегда зло.
Просто разница в том что в REST API по
GET /add/2/2
POST /add
нельзя сказать какое решение однозначно плохое а какое однозначно хорошее.
А в вашем примере с SOAP конечно же такое встречалось очень часто. Последний раз в прошлом году видел подобное. За редким исключением чаще всего можно было легко упростить решение. А в редких случаях использование SOAP было просто неоправдано в этом API.
Да нет, это как раз аргумент. То, что вам он не подходит — это ваше дело.
Поправьте если я ошибаюсь: Проще говоря, Вы утверждаете что статус коды правильно будет смешивать с логикой, но если это нам не подходит то это уже наши проблемы?
И будете писать такой для каждого сервиса, с которым вы взаимодействуете, учитывая, что у каждого из них новый формат?
тут два варианта. Внешние сервисы которые написаны не вами. Тогда вам так и так придется пилить свое решение под каждый внешний сервис, потому как REST API в отличае от того же строго но тяжеловесного SOAP, дает очень много свободы и трактовки и каждый реализует как хочет. В таком случае так и так под каждый сервис приходится пилить свое решение.
Внутренние сервисы/микросервисы которые разрабатывают внутри компании. В таком случае у вас есть возможность договориться о едином формате (собственно рано или поздно всегда приходят к этому выводу и договориваются о том что бы придти к единому формату). В таком случае только один раз тюнится/надстраивается библиотека типа refit (C#)/ retrofit (Java) и его аналоги в разных языках, под то что договорились в компании и все команды используют эту библиотеку.
И на самом деле тут уже не важно есть статус коды или нет, потому как под сложные потребности которые выходят за рамки простых сущностей приходится так и так договариваться как правильно делать.
Допустим потребовался сервис который складывает два числа. Строгий SOAP просто не допустит разночтения.
А в REST одна команда может сделать в виде
GET /add/2/2
другая команда сделает
POST /add
{
"a": 2,
"b":2
}
Третья решит сделать еще
POST /operations
{
"add"
И т.д.
Так что в сложных задачах в REST практически всегда приходится договариваться о единых стандартах для всех команд
я могу воткнуть простейшее response.EnsureSuccessStatusCode() и быть уверенным, что если проверка прошла, мой запрос был успешно выполнен сервером.
Вот главная причина на самом деле. Но опять таки это не аргумент. В приложении для школ мы сделали аналогичный метод расширение в духе response.IsSuccesss() который смотрел уже не на статус а на коды ошибок в теле.
Первая реализация был метод где то в 20 строк кода который позволял работать с 200 статусом ровно так же как могли работать со HTTP статус кодами. Эти 20 строк кода решило огромную бизнес проблему.
Но в случае ошибок это решение работало медленее так как приходилось второй раз десериализовывать ответ в объект с ошибкой.
А потом сделали вторую реализацию, не потому что первое решение работало медленее. Из соображений перфекционизма, где реализовали собственную логику десериализации, что бы десериализация делалась бы за один проход.
Оно было заточено конкретно под наше API Но работало так же быстро как со статус кодами. Но кода там было где то в 150-200 строк кода.
Хорошо, какие аргументы Вы можете привести в пользу статус кодов если так и так ошибку приходится возвращать в теле? Зачем дублировать одну и ту же информацию дважды в двух местах? Я лично вижу только одно преимущество — производительность.
В том то и дело что иногда статус коды отменяют тело. Лет 10-15 назад с этим были большие проблемы у крупных компаний. Но постепенно настроили инфрастуктуру. Но даже сейчас не все проекты делаются для модных молодежных клиентов с современной инфраструктурой. Опять таки в приложении для школ в каких нибудь регионах/селах, админы приезжают за десятки километров и настраивают школьную сеть/прокси и т.п. У них все уже работает как надо. С фильтрами взрослых ресурсов и т.п. Ну у тебя выбор. Или перейти на 200 и добавить в приложении несколько лишних строк кода. Или ходить по школам просить купить ваш продукт и при этом требовать перестроить их прокси для работы вашего приложения в школе. Как думаете, какой выбор сделает бизнес?
Я что-то так и не увидел ответа, какая же разница, почему отдали 404.
Я уже не уверен что вы не придираетесь. Я же привел аналогичный пример про 400 который вы проигнорировали и все равно прицепились именно к 404.
404 это еще один пример.
Если url не существует, значит накосячили с URL. А в больших проектах их за 300+ и такое часто случается.
Когда API делают быстро очень часто случается лютый говнокод с API.
А в проекте решили заюзать аналог refit/retrofit что бы упростить работу с API. Может разработчик неправильно описал refit аттрибуты? Или же все правильно но просто запись не найдена? Может url переехал а приложение просто забыли обновить? А все ищут ошибку в базе данных. Это простешие проблемы связанные с ошибками с элементарных API. А когда API намного сложнее то и проблемы получаются гораздо изощеренее.
Смешивание кодов упрощает разработчику жизнь на этапе написания кода.
Но усложняет жизнь на этапе поддержки.
И чем больше проект и тем больше эти проблемы.
Посмотрите, к примеру, API практически всех крупных проектов. VK, Facebook и т.д. и т.п. Они отказались от статусов и реализовали свои коды ошибок не просто так.
Разница большая:
Надо осознавать что в REST API решили наложить логические ошибки на ошибки веб сервера не потому что было правильно смешивать ошибки сервера и ошибки приложения, а по одной очень простой причине — производительность.
Намного быстрее посмотреть статус и направить обработку в разные ветки нежели парсить ответ а потом реагировать.
Но за это в сложных сценариях приходится платить свою цену:
Допустим у тебя клиентское приложение словило, например, 400.
У тебя POST запрос большой структуры данных (где то 150 полей + 5 уровней вложенности). Тебе приходит 400. СХЕМА данных в принципе неправильно собрана? (В таком случае фреймворк даст 400). Или 400 был логический ответ на валидацию ЗНАЧЕНИЙ? В первом случае ошибка в логике приложения, допустили рассинхрон данных. Значит проблему нельзя исправить на стороне пользователя. Во втором случае надо провалидировать значения и попросить пользователя исправить ошибку.
В другом случае со школами пришлось перейти на 200 статус везде и парсить тело всегда. Заметно медленне это не стало работать. Но зато стало работать гораздо стабильнее и надежнее. И сильно сократился объем ошибок. И кроме того гораздо упростился разбор ошибок — если возникали ошибки подключения к серверу то было понятно что это гарантированно не логические ошибки приложения на сервере и/или клиенте и надо искать в инфраструктуре.
Изначально статус коды HTTP придумали именно как статус коды вебсервера, а не приложения как их используют в REST.
Их придумали глупые люди?
Их придумали не для REST API. Их придумали для унификации ошибок веб сервера, а вот уже намного позже придумали REST API где решили наложить логические ошибки на ошибки веб-сервера.
К примеру сервер отвечает 404. Сервер ответил 404 потому что такого URL не существует? Или сервер нашел ресурс но ответил 404 потому что разработчик реализовал бизнес логику через 404 статус? Вот его придумали для первого случая но не для второго.
Отсюда вывод что если пришел 404 то ты обязан посмотреть тело ответа что бы убедиться что это логическая ошибка а не инфраструктурная, доменная и т.п.
В двух больших проектах именно с этим был большой геморрой. Когда появился REST API и пошел хайп, архитекторы приняли вот такое гениальное решение использовать REST API для крупного проекта и наложить статус коды для передачи ошибок между серверами.
Но так как это было распределенное приложение в нескольких странах оказалось что датацентры компании настроены таким образом что они режут тело ответа 500-тых ошибок из соображений безопасности. Потому что изначально 500 отдавали когда произошел какой то непредвиденный сбой, и что бы скрыть тело от лишних глаз, никто не предполагал что 5xx как умышленный ответ. REST API проектировался для работы с сущностями. Соответственно нам попросту перестало хватать кодов для передачи разного типа ошибок.
Дошло до обсруда что решили делать гибридные ошибки. Если пришел 4xx, 5xx то ты еще должен доуточнить чтением отдельного кода в теле что именно за ошибка была
В другом проекте для школ оказалось что многие школы работают за прокси. Соответственно школьные прокси резали/меняли статус коды ошибок кроме 200 со всеми вытекающими последствиями.
Последнее время, так как теперь уже REST API прошел волну хайпа, с этими проблемами стало получше. Но все же надо знать матчасть и историю, прежде чем осуждать других
Мне реально, очень стыдно, в прямом смысле, за тех, кто минусует попытку автора поднять этот вопрос.
Не надо переходить на личности. Так можно сказать что "мне реально стыдно за тех кому стыдно за других хотя сам не разобрался в матчасти, не знает истории, нет опыта работы в больших проектах". Если вы правы то вас поймут и без перехода на личности
В принципе интересно было бы купить эту книгу у вас и я постоянно у вас закупался раньше, но с каждым днем ваш сервис все хуже и хуже.
В прошлый раз я заказал у вас 5 книг из которых два экземпляра относительно недавно изданной вами книги "Чистый код: создание, анализ и рефакторинг". Мне пришли три вторичные книги без 2 книг ради которого и оформлял заказ в принципе. Доставили заранее никак не уведомив что книг не будет или как то еще.
Когда я позвонил по телефону сказали что потом доставят, а я попросил как то уведомить меня о том что я все таки получу эти книги.
Сейчас в личном кабинете у меня светится что я все получил (нет, не получил). Ни одного письма или сообщения до сих пор не было, хотя прошло чуть больше месяца.
Хотелось бы узнать какие шансы что я снова куплю у вас книги и опять ничего не получу. (про извинияния и уведомления о том когда исправите свою оплошность я уже и не мечтаю).
Я работал во многих командах где на C# так и пишут. Но опять таки, как было замечено выше, на C# писать в таком стиле это боль. Когда тебе сдают проект с 1,3 млн. строк кода, без тестов, без организации без структуры (ну и естественно со всеми нарушениями принципа SOLID и DDD). Это боль. Очень большая боль.
Все эти SOLID, DDD, DI, интерфейс на каждый чих и т.п. получили популярность в Enterpise секторе не из за того что разработчики страдают мазохизмом а из за того что они решают конкретную проблему больших проектов.
Просто когда видишь что можно поменять мышление, можно по другому взглянуть на проблему и это позволит убрать этот мусор то уже трудно заставить писать все это.
И почему думаете что SOLID и ФП несовместимы? Если довести SOLID принципы до абсурда то у тебя практически получится функциональный подход. (на самом деле не совсем так но это тема отдельной статьи).
Возьмем например букву S. (Принцип единственной ответственности). Одна функция одна ответственность. Схожий принцип I (принцип разделения интерфейсов) — один интерфейс — один метод — одна функция и т.д. по всем остальным принципам.
Посмотрите еще насколько проще воплощается DDD на F# по сравнению с реализацией DDD на C#. https://fsharpforfunandprofit.com/ddd/
В больших проектах SOLID и DDD это манна небесная которая реально спасает разработку. Но на F# эти принципы соблюдать еще проще чем на C#
Задело за живое. К сожалению с F# есть одна проблема. Если повезет то ты просто не поймешь что за язык, или будешь пытаться писать на нем ровно так же как пишешь на С# (ставя везде mutable). А вот если не повезет то ты поймешь насколько это крутой и насколько недооцененный язык. Ты уже заразился, для каждой задачи ты уже видишь два решения: C# стиль (с кучой мусора на интерфейсах и DI) или F# стиль. Давным давно я когда то влюбился в C# после нескольких язков и я был счастлив. А сейчас: хорошая зарплата, начальство, риск менеджмент, кадровая политика и т.д. и т.п. прибивают разработку гвоздями к C# но я уже несчастлив. Эта бесконечная вереница интерфейсов, скобочек и безумного количества мусорного кода с пробрасыванием интерфейсов, наследования от интерфесов, где у 99,99% интерфейсов всего одна единственная реализаця. Слава богу есть Resharper, который хотя бы хорошо автоматизирует генерацию этого адского, бесползеного, не приносящего никакой прямой пользы мусора. Но ты понимаешь что можно было бы идти по другому пути — пути где не надо было генерировать и поддерживать этот мусор и ты несчастлив что смалодушничал и выбрал более теплый, мягкий, безопасный путь бесконечного мусорного кода типичной Enterprise разработки.
Конкретно эта статья и оригинал статьи на F# это типичный пример того как категорически нельзя писать бизнес логику. И то как, к большому сожалению, многие пишут бизнес логику.
Проблема этого кода в том что пока два типа Post, Email у тебя получается всего три варианта возможных значений: PostOnly, EmailOnly, PostAndEmail, и соответственно если бизнес попросит добавить третье значение то образуется "комбинаторный взрыв" Phone, Email, Post, PhoneAndEmail, PhoneAndPost, EmailAndPost, PhoneAndEmailAndPost. А в примере на C# на каждый из них надо модифицировать тонну C# код с наследованием, визиторами и т.д. и т.п. А если бизнес попросит 4-тый (рабочий адрес/телефон)? 5-тый?
Но, как показывает практика, благодаря тому что статья заканчивается на таких вот примерах и призывает делать такое решение проблем бизнеса, большинство дальше и не читает. И в итоге несмотря на то что статья призывает к прекрасному, такая подача материала наносит большой вред и разработчики приходят к выводу что функциональщина "неработающий на практике, оторваный от реальности, малоприменимый отстой"
На самом деле расстраиваться из за такого собеседования не стоит. Любое собеседование является обоюдным. Надо радоваться когда человек с которым ты будешь работать сразу показывает свое лицо. Было бы гораздо хуже если бы взяли на такую работу, а потом показали бы свое лицо. Не знать что такое virtual для ведущего разработчика, это, конечно, плохо. Но еще хуже если собеседующий радуется и не может даже скрыть своей радости по этому поводу. Думаю стоит порадоваться что провалили это собеседование.
Я часто сталкивался с аналогичной проблемой когда консультировал команды на Xamarin. Не обязательно все что может понадобиться и не понадобиться использовать на старте и инициализировать все. Можно декомпозировать приложение, сделать Lazy инициализацию компонент, выделить модули и приложение начнет запускаться намного быстрее.
flutter на хайпе но еще сырой и плохо развит инструментарий и тем более вряд ли можно считать его популярным по сравнению с ReactNative или Xamarin (достаточно легко в этом убедиться если сделать поиск на любом сайте с работами). Но относительно статьи можете считать что аналогом flutter является React Native.
Большое спасибо за статью! Очень интересно. Однако начав изучать сайт неожиданно обнаружил что много где используется Angular 5 https://app.repetitor.school/exams (ng-version=5.2.5)
Хотя пишете что клиент писали на ReactJS
Можете подробнее рассказать про этот момент?
Спасибо за перевод! Но возможно не надо частично/дословно переводить "CSS Grid" как "CSS-Сетка", так как все таки это неделимое название спецификации (или инструмента/технологии как Вы назвали). Это все равно что перводить Flexbox, Sketch и т.п.
Раньше при покупке бумажной книги также давались ссылки на электронную версию (при условии что электронная версия доступна). Сейчас уже отменили эту практику?
(За последние две книжки React и Angular не приходило никакой ссылки на электронную книгу). Кстати если не снабжаете электронной книгой хорошо бы наконец получить бумажную версию которую я заплатил 9 дней назад (Angular)
Судя по System.Diagnostics вы, скорее всего, .NET разработчик. В .NET намного проще работать с REST API на статус кодах и сильно упрощает поддержку и разработку.
Как вы поняли, я тоже работал в нескольких проектах с REST API со статус кодами, так и с REST API на 200 статусе.
Я не говорю что статус коды однозначеное зло. Наоборот. в .NET мире гораздо проще работать с REST API на статус кодах так как и сервер ASP.NET и HttpClient заточены под это. Я всего лишь прошу не утверждать что 200 это всегда неправильно и за это надо кого то стыдить. Иногда гораздо проще делать решения на 200 тых кода как с точки зрения бизнеса так и с точки зрения поддержки легаси инфраструктуры. И обходится это гораздо дешевле чем переделывание легаси.
Но я могу понять вашу точку зрения так как, в отличае от других языков в .Net мире нет такого богатого выбора разных фремворков и клиентов.(точнее альтернативы и выбор есть но их популярность по отношению к базовым на уровне погрешности, так как базовых обычно хватает с лихвой).
Насчет примера с SOAP злоупотребления всегда зло.
Просто разница в том что в REST API по
GET /add/2/2
POST /add
нельзя сказать какое решение однозначно плохое а какое однозначно хорошее.
А в вашем примере с SOAP конечно же такое встречалось очень часто. Последний раз в прошлом году видел подобное. За редким исключением чаще всего можно было легко упростить решение. А в редких случаях использование SOAP было просто неоправдано в этом API.
Поправьте если я ошибаюсь: Проще говоря, Вы утверждаете что статус коды правильно будет смешивать с логикой, но если это нам не подходит то это уже наши проблемы?
тут два варианта. Внешние сервисы которые написаны не вами. Тогда вам так и так придется пилить свое решение под каждый внешний сервис, потому как REST API в отличае от того же строго но тяжеловесного SOAP, дает очень много свободы и трактовки и каждый реализует как хочет. В таком случае так и так под каждый сервис приходится пилить свое решение.
Внутренние сервисы/микросервисы которые разрабатывают внутри компании. В таком случае у вас есть возможность договориться о едином формате (собственно рано или поздно всегда приходят к этому выводу и договориваются о том что бы придти к единому формату). В таком случае только один раз тюнится/надстраивается библиотека типа refit (C#)/ retrofit (Java) и его аналоги в разных языках, под то что договорились в компании и все команды используют эту библиотеку.
И на самом деле тут уже не важно есть статус коды или нет, потому как под сложные потребности которые выходят за рамки простых сущностей приходится так и так договариваться как правильно делать.
Допустим потребовался сервис который складывает два числа. Строгий SOAP просто не допустит разночтения.
А в REST одна команда может сделать в виде
GET /add/2/2
другая команда сделает
POST /add
{
"a": 2,
"b":2
}
Третья решит сделать еще
POST /operations
{
"add"
И т.д.
Так что в сложных задачах в REST практически всегда приходится договариваться о единых стандартах для всех команд
Вот главная причина на самом деле. Но опять таки это не аргумент. В приложении для школ мы сделали аналогичный метод расширение в духе response.IsSuccesss() который смотрел уже не на статус а на коды ошибок в теле.
Первая реализация был метод где то в 20 строк кода который позволял работать с 200 статусом ровно так же как могли работать со HTTP статус кодами. Эти 20 строк кода решило огромную бизнес проблему.
Но в случае ошибок это решение работало медленее так как приходилось второй раз десериализовывать ответ в объект с ошибкой.
А потом сделали вторую реализацию, не потому что первое решение работало медленее. Из соображений перфекционизма, где реализовали собственную логику десериализации, что бы десериализация делалась бы за один проход.
Оно было заточено конкретно под наше API Но работало так же быстро как со статус кодами. Но кода там было где то в 150-200 строк кода.
Хорошо, какие аргументы Вы можете привести в пользу статус кодов если так и так ошибку приходится возвращать в теле? Зачем дублировать одну и ту же информацию дважды в двух местах? Я лично вижу только одно преимущество — производительность.
В том то и дело что иногда статус коды отменяют тело. Лет 10-15 назад с этим были большие проблемы у крупных компаний. Но постепенно настроили инфрастуктуру. Но даже сейчас не все проекты делаются для модных молодежных клиентов с современной инфраструктурой. Опять таки в приложении для школ в каких нибудь регионах/селах, админы приезжают за десятки километров и настраивают школьную сеть/прокси и т.п. У них все уже работает как надо. С фильтрами взрослых ресурсов и т.п. Ну у тебя выбор. Или перейти на 200 и добавить в приложении несколько лишних строк кода. Или ходить по школам просить купить ваш продукт и при этом требовать перестроить их прокси для работы вашего приложения в школе. Как думаете, какой выбор сделает бизнес?
Я уже не уверен что вы не придираетесь. Я же привел аналогичный пример про 400 который вы проигнорировали и все равно прицепились именно к 404.
404 это еще один пример.
Если url не существует, значит накосячили с URL. А в больших проектах их за 300+ и такое часто случается.
Когда API делают быстро очень часто случается лютый говнокод с API.
А в проекте решили заюзать аналог refit/retrofit что бы упростить работу с API. Может разработчик неправильно описал refit аттрибуты? Или же все правильно но просто запись не найдена? Может url переехал а приложение просто забыли обновить? А все ищут ошибку в базе данных. Это простешие проблемы связанные с ошибками с элементарных API. А когда API намного сложнее то и проблемы получаются гораздо изощеренее.
Смешивание кодов упрощает разработчику жизнь на этапе написания кода.
Но усложняет жизнь на этапе поддержки.
И чем больше проект и тем больше эти проблемы.
Посмотрите, к примеру, API практически всех крупных проектов. VK, Facebook и т.д. и т.п. Они отказались от статусов и реализовали свои коды ошибок не просто так.
Другой пример Twitter: https://developer.twitter.com/en/docs/basics/response-codes
Статус коды дополнены кодами ошибок приложения
Разница большая:
Надо осознавать что в REST API решили наложить логические ошибки на ошибки веб сервера не потому что было правильно смешивать ошибки сервера и ошибки приложения, а по одной очень простой причине — производительность.
Намного быстрее посмотреть статус и направить обработку в разные ветки нежели парсить ответ а потом реагировать.
Но за это в сложных сценариях приходится платить свою цену:
Допустим у тебя клиентское приложение словило, например, 400.
У тебя POST запрос большой структуры данных (где то 150 полей + 5 уровней вложенности). Тебе приходит 400. СХЕМА данных в принципе неправильно собрана? (В таком случае фреймворк даст 400). Или 400 был логический ответ на валидацию ЗНАЧЕНИЙ? В первом случае ошибка в логике приложения, допустили рассинхрон данных. Значит проблему нельзя исправить на стороне пользователя. Во втором случае надо провалидировать значения и попросить пользователя исправить ошибку.
В другом случае со школами пришлось перейти на 200 статус везде и парсить тело всегда. Заметно медленне это не стало работать. Но зато стало работать гораздо стабильнее и надежнее. И сильно сократился объем ошибок. И кроме того гораздо упростился разбор ошибок — если возникали ошибки подключения к серверу то было понятно что это гарантированно не логические ошибки приложения на сервере и/или клиенте и надо искать в инфраструктуре.
Изначально статус коды HTTP придумали именно как статус коды вебсервера, а не приложения как их используют в REST.
Их придумали не для REST API. Их придумали для унификации ошибок веб сервера, а вот уже намного позже придумали REST API где решили наложить логические ошибки на ошибки веб-сервера.
К примеру сервер отвечает 404. Сервер ответил 404 потому что такого URL не существует? Или сервер нашел ресурс но ответил 404 потому что разработчик реализовал бизнес логику через 404 статус? Вот его придумали для первого случая но не для второго.
Отсюда вывод что если пришел 404 то ты обязан посмотреть тело ответа что бы убедиться что это логическая ошибка а не инфраструктурная, доменная и т.п.
В двух больших проектах именно с этим был большой геморрой. Когда появился REST API и пошел хайп, архитекторы приняли вот такое гениальное решение использовать REST API для крупного проекта и наложить статус коды для передачи ошибок между серверами.
Но так как это было распределенное приложение в нескольких странах оказалось что датацентры компании настроены таким образом что они режут тело ответа 500-тых ошибок из соображений безопасности. Потому что изначально 500 отдавали когда произошел какой то непредвиденный сбой, и что бы скрыть тело от лишних глаз, никто не предполагал что 5xx как умышленный ответ. REST API проектировался для работы с сущностями. Соответственно нам попросту перестало хватать кодов для передачи разного типа ошибок.
Дошло до обсруда что решили делать гибридные ошибки. Если пришел 4xx, 5xx то ты еще должен доуточнить чтением отдельного кода в теле что именно за ошибка была
В другом проекте для школ оказалось что многие школы работают за прокси. Соответственно школьные прокси резали/меняли статус коды ошибок кроме 200 со всеми вытекающими последствиями.
Последнее время, так как теперь уже REST API прошел волну хайпа, с этими проблемами стало получше. Но все же надо знать матчасть и историю, прежде чем осуждать других
Не надо переходить на личности. Так можно сказать что "мне реально стыдно за тех кому стыдно за других хотя сам не разобрался в матчасти, не знает истории, нет опыта работы в больших проектах". Если вы правы то вас поймут и без перехода на личности
В принципе интересно было бы купить эту книгу у вас и я постоянно у вас закупался раньше, но с каждым днем ваш сервис все хуже и хуже.
В прошлый раз я заказал у вас 5 книг из которых два экземпляра относительно недавно изданной вами книги "Чистый код: создание, анализ и рефакторинг". Мне пришли три вторичные книги без 2 книг ради которого и оформлял заказ в принципе. Доставили заранее никак не уведомив что книг не будет или как то еще.
Когда я позвонил по телефону сказали что потом доставят, а я попросил как то уведомить меня о том что я все таки получу эти книги.
Сейчас в личном кабинете у меня светится что я все получил (нет, не получил). Ни одного письма или сообщения до сих пор не было, хотя прошло чуть больше месяца.
Хотелось бы узнать какие шансы что я снова куплю у вас книги и опять ничего не получу. (про извинияния и уведомления о том когда исправите свою оплошность я уже и не мечтаю).
Я работал во многих командах где на C# так и пишут. Но опять таки, как было замечено выше, на C# писать в таком стиле это боль. Когда тебе сдают проект с 1,3 млн. строк кода, без тестов, без организации без структуры (ну и естественно со всеми нарушениями принципа SOLID и DDD). Это боль. Очень большая боль.
Все эти SOLID, DDD, DI, интерфейс на каждый чих и т.п. получили популярность в Enterpise секторе не из за того что разработчики страдают мазохизмом а из за того что они решают конкретную проблему больших проектов.
Просто когда видишь что можно поменять мышление, можно по другому взглянуть на проблему и это позволит убрать этот мусор то уже трудно заставить писать все это.
И почему думаете что SOLID и ФП несовместимы? Если довести SOLID принципы до абсурда то у тебя практически получится функциональный подход. (на самом деле не совсем так но это тема отдельной статьи).
Возьмем например букву S. (Принцип единственной ответственности). Одна функция одна ответственность. Схожий принцип I (принцип разделения интерфейсов) — один интерфейс — один метод — одна функция и т.д. по всем остальным принципам.
Посмотрите еще насколько проще воплощается DDD на F# по сравнению с реализацией DDD на C#.
https://fsharpforfunandprofit.com/ddd/
В больших проектах SOLID и DDD это манна небесная которая реально спасает разработку. Но на F# эти принципы соблюдать еще проще чем на C#
Задело за живое. К сожалению с F# есть одна проблема. Если повезет то ты просто не поймешь что за язык, или будешь пытаться писать на нем ровно так же как пишешь на С# (ставя везде mutable). А вот если не повезет то ты поймешь насколько это крутой и насколько недооцененный язык. Ты уже заразился, для каждой задачи ты уже видишь два решения: C# стиль (с кучой мусора на интерфейсах и DI) или F# стиль. Давным давно я когда то влюбился в C# после нескольких язков и я был счастлив. А сейчас: хорошая зарплата, начальство, риск менеджмент, кадровая политика и т.д. и т.п. прибивают разработку гвоздями к C# но я уже несчастлив. Эта бесконечная вереница интерфейсов, скобочек и безумного количества мусорного кода с пробрасыванием интерфейсов, наследования от интерфесов, где у 99,99% интерфейсов всего одна единственная реализаця. Слава богу есть Resharper, который хотя бы хорошо автоматизирует генерацию этого адского, бесползеного, не приносящего никакой прямой пользы мусора. Но ты понимаешь что можно было бы идти по другому пути — пути где не надо было генерировать и поддерживать этот мусор и ты несчастлив что смалодушничал и выбрал более теплый, мягкий, безопасный путь бесконечного мусорного кода типичной Enterprise разработки.
Конкретно эта статья и оригинал статьи на F# это типичный пример того как категорически нельзя писать бизнес логику. И то как, к большому сожалению, многие пишут бизнес логику.
Проблема этого кода в том что пока два типа Post, Email у тебя получается всего три варианта возможных значений: PostOnly, EmailOnly, PostAndEmail, и соответственно если бизнес попросит добавить третье значение то образуется "комбинаторный взрыв" Phone, Email, Post, PhoneAndEmail, PhoneAndPost, EmailAndPost, PhoneAndEmailAndPost. А в примере на C# на каждый из них надо модифицировать тонну C# код с наследованием, визиторами и т.д. и т.п. А если бизнес попросит 4-тый (рабочий адрес/телефон)? 5-тый?
Автор сам делает развитие этой мысли и решение в следующей статье: https://fsharpforfunandprofit.com/posts/designing-with-types-discovering-the-domain/
Но, как показывает практика, благодаря тому что статья заканчивается на таких вот примерах и призывает делать такое решение проблем бизнеса, большинство дальше и не читает. И в итоге несмотря на то что статья призывает к прекрасному, такая подача материала наносит большой вред и разработчики приходят к выводу что функциональщина "неработающий на практике, оторваный от реальности, малоприменимый отстой"
На самом деле расстраиваться из за такого собеседования не стоит. Любое собеседование является обоюдным. Надо радоваться когда человек с которым ты будешь работать сразу показывает свое лицо. Было бы гораздо хуже если бы взяли на такую работу, а потом показали бы свое лицо. Не знать что такое virtual для ведущего разработчика, это, конечно, плохо. Но еще хуже если собеседующий радуется и не может даже скрыть своей радости по этому поводу. Думаю стоит порадоваться что провалили это собеседование.
Я часто сталкивался с аналогичной проблемой когда консультировал команды на Xamarin. Не обязательно все что может понадобиться и не понадобиться использовать на старте и инициализировать все. Можно декомпозировать приложение, сделать Lazy инициализацию компонент, выделить модули и приложение начнет запускаться намного быстрее.
При желании можно подключить любую нативную библиотеку написанную на Java
https://docs.microsoft.com/ru-ru/xamarin/android/platform/binding-java-library/
Так же для большинства наиболее популярных библиотек есть готовые обертки которые можно подключить из nuget-а.
Однако в случае retorfit проще использовать порт этой библиотеки на .net
https://www.nuget.org/packages/refit/
https://github.com/reactiveui/refit
flutter на хайпе но еще сырой и плохо развит инструментарий и тем более вряд ли можно считать его популярным по сравнению с ReactNative или Xamarin (достаточно легко в этом убедиться если сделать поиск на любом сайте с работами). Но относительно статьи можете считать что аналогом flutter является React Native.
Большое спасибо за статью! Очень интересно. Однако начав изучать сайт неожиданно обнаружил что много где используется Angular 5
https://app.repetitor.school/exams (ng-version=5.2.5)
Хотя пишете что клиент писали на ReactJS
Можете подробнее рассказать про этот момент?
Еще немного занудства. Обычно сокращенное название спецификации пишется как "CSS Grid" а не "CSS-grid"
Спасибо за перевод! Но возможно не надо частично/дословно переводить "CSS Grid" как "CSS-Сетка", так как все таки это неделимое название спецификации (или инструмента/технологии как Вы назвали). Это все равно что перводить Flexbox, Sketch и т.п.
Заказал бумажную книжку. Ссылка на цифру тоже пришла.
Раньше при покупке бумажной книги также давались ссылки на электронную версию (при условии что электронная версия доступна). Сейчас уже отменили эту практику?
(За последние две книжки React и Angular не приходило никакой ссылки на электронную книгу). Кстати если не снабжаете электронной книгой хорошо бы наконец получить бумажную версию которую я заплатил 9 дней назад (Angular)