Сначала объясните, пожалуйста, что Вы понимаете под стандартным REST-подходом. Чувствую, имеет место недопонимание. На всякий случай напоминаю, я отвечал на коммент, где предлагалось делать так:
500 {ok: false, message: 'SMTP relay fail: code 1234', trace: ['/path/to','/bla/bla','/lib/smtp',...]} — ошибка кода. когда возник необработанные ексепшн
500: {ok: false, message: 'user is not activated yet'} — ошибка бизнесс-логики
По-вашему получается, что 200-е нельзя разделить между собой, а 500-е — можно.
Но это все ни о чем. Смысл заключается в фиксированных классах ошибок — чтобы клиент мог правильно обработать любую, в т.ч. новую, ошибку. В общем, если честно, Ваш пример настолько корявый, что обсуждать даже не хочется. Уберите статус коды, и увидите, что они просто лишние.
А сама проблема лежит глубже — REST смешивает транспортный и прикладной уровень, и подход "200 на все" эту проблему решает (правда, делая REST не нужным вообще).
всё остальное (и не важно, пропала сеть, неправльный урл, ошибка сервера, ошибка БЛ, да хоть апокалипсис) — это не получилось, тобишь ошибка.
Крайне, крайне ограниченный подход. Вам, как минимум, надо знать, произошла ли ошибка по вине сервера (и можно попробовать позже) или клиента (повторять такой же запрос бессмысленно).
Плюс к экзепшенам, правильно разделенных по типам. Они позволяют строить действительно структурированный код. Если ошибка при вызове метода API была на уровне транспорта (а в случае REST API это еще надо разобраться, ха-ха) — бросаем исключение технического типа и не обрабатываем его на уровне бизнес-логики.
когда нагрузка по непосредственной работе с кодом осталась в прошлом, уступив исключительно менеджерским обязанностям,… деятельность становится более понятной и прозрачной окружающим
Мое мнение — надо стремиться делать специализацию ортогональной другим свойствам организации. Весь прогресс построен на специализации, и ее роль будет только расти.
> Так в 286/386 машинах точно также страничная адресация по 64К
Это совсем разная страничная адресация.
В ZX-128 16K банки памяти «втыкались» в одно из двух фиксированных мест в адресном пространстве в 64K записью команды в определенный порт. Проц всегда работал с 64К-пространством и даже не знал, что там сейчас подключено.
В 286 — это была просто хитрая адресация сегмент: смещение. Сами сегменты накладывались друг на друга, и это было реализовано аппаратно. Адрес перехода можно было указать или абсолютный в формате сегмент: смещение, или относительный (относительно текущего IP, если говорить о переходах), но не более 32K в ту или другую сторону. Отсюда размер com-файлов (кстати, они могут быть больше 64K) — важно то, что они не были релоцируемыми, все переходы в них относительные.
> Я как раз сказал что использовать адресное пространство портов
OMG, чуваки, это была первоапрельская шутка от ZX Ревю, легенда которой заключалась в том, что к 64K можно добавить еще софтовым путем, «всего лишь» задействовав адресное пространство портов. Естественно, это не возможно по целому ряду причин.
Мы верим в специализацию. У нас есть команда, сотрудники которой только и делают, что пишут юнит-тесты.
А как же полноценные команды, владеющие продуктом, DevOps, и тому подобные веяния? Хотелось бы услышать побольше мыслей/идей/обоснований, т.к. давно волнует этот вопрос. Спасибо.
если ты таксист, езжай ровнее, чтобы никого по салону не бросало.
Вот-вот, езжай ровнее и на дорогу смотри, а не о высоких материях рассуждай. Что большинство действительно хороших разработчиков с успехом и делает.
Кстати,
У меня вообще нет никакого высокомерия по отношению к разработчикам, матана не ведающим.
Пожалуйста, продемонстрируйте Ваш код. Или пример декомпозиции задачи. Или набросок архитектуры приложения. Или схему БД. Или книгу статейку какую-нибудь. Главное, чтобы там был матан. А мы оценим, и, может быть, восхитимся.
Лучше вообще никак не объяснять, а так — тем более.
Сначала объясните, пожалуйста, что Вы понимаете под стандартным REST-подходом. Чувствую, имеет место недопонимание. На всякий случай напоминаю, я отвечал на коммент, где предлагалось делать так:
По-вашему получается, что 200-е нельзя разделить между собой, а 500-е — можно.
Но это все ни о чем. Смысл заключается в фиксированных классах ошибок — чтобы клиент мог правильно обработать любую, в т.ч. новую, ошибку. В общем, если честно, Ваш пример настолько корявый, что обсуждать даже не хочется. Уберите статус коды, и увидите, что они просто лишние.
А сама проблема лежит глубже — REST смешивает транспортный и прикладной уровень, и подход "200 на все" эту проблему решает (правда, делая REST не нужным вообще).
Крайне, крайне ограниченный подход. Вам, как минимум, надо знать, произошла ли ошибка по вине сервера (и можно попробовать позже) или клиента (повторять такой же запрос бессмысленно).
Плюс к экзепшенам, правильно разделенных по типам. Они позволяют строить действительно структурированный код. Если ошибка при вызове метода API была на уровне транспорта (а в случае REST API это еще надо разобраться, ха-ха) — бросаем исключение технического типа и не обрабатываем его на уровне бизнес-логики.
Весьма спорно...
Понятно, спасибо.
Мое мнение — надо стремиться делать специализацию ортогональной другим свойствам организации. Весь прогресс построен на специализации, и ее роль будет только расти.
Это совсем разная страничная адресация.
В ZX-128 16K банки памяти «втыкались» в одно из двух фиксированных мест в адресном пространстве в 64K записью команды в определенный порт. Проц всегда работал с 64К-пространством и даже не знал, что там сейчас подключено.
В 286 — это была просто хитрая адресация сегмент: смещение. Сами сегменты накладывались друг на друга, и это было реализовано аппаратно. Адрес перехода можно было указать или абсолютный в формате сегмент: смещение, или относительный (относительно текущего IP, если говорить о переходах), но не более 32K в ту или другую сторону. Отсюда размер com-файлов (кстати, они могут быть больше 64K) — важно то, что они не были релоцируемыми, все переходы в них относительные.
OMG, чуваки, это была первоапрельская шутка от ZX Ревю, легенда которой заключалась в том, что к 64K можно добавить еще софтовым путем, «всего лишь» задействовав адресное пространство портов. Естественно, это не возможно по целому ряду причин.
«Идея» там была такая: у нас есть 64К адресов в памяти, но ведь есть же еще 64K портов, давайте их юзать как память :)
8-ми битные компьютеры — это то, что перевернуло ход истории. То, благодаря чему Вы сейчас пишете эти строки.
Давайте еще детей выкинем, нафиг они нужны, ничего не умеют.
> создать из 8-битного микроконтроллера компьютер
Да Вы вообще не владеете предметной областью.
Пример кроссплатформенного редактирования скомпилированной функции в студию, пожалуйста. Сравним с вызовом eval().
А как же полноценные команды, владеющие продуктом, DevOps, и тому подобные веяния? Хотелось бы услышать побольше мыслей/идей/обоснований, т.к. давно волнует этот вопрос. Спасибо.
Quazatron: www.youtube.com/watch?v=Y2eSjTdWYsU
Savage 2: www.youtube.com/watch?v=IR1TWDocL_M&t=7s
И даже это больше говорит о Вас, нежели о мире.
Вопрос автору: насколько глубоко надо знать то, что происходит после нажатия кнопки включения ПК, чтобы считаться профессионалом?
Вы сделали этот вывод на основании одного эпизода?
Я понимаю, продемонстрируйте свои решения, созданные под влиянием мышления, отточенного матаном.
Вот-вот, езжай ровнее и на дорогу смотри, а не о высоких материях рассуждай. Что большинство действительно хороших разработчиков с успехом и делает.
Кстати,
Пожалуйста, продемонстрируйте Ваш код. Или пример декомпозиции задачи. Или набросок архитектуры приложения. Или схему БД. Или
книгустатейку какую-нибудь. Главное, чтобы там был матан. А мы оценим, и, может быть, восхитимся.Это большое преувеличение.