REST API Best Practices

Это я уже запутался. Вы правы, 404 тут как раз и должен возвращаться. Можете 418 попробовать (;

А на практике у меня обычно
404 {ok: false, message: 'not found'} для отсутствия ендпоинта
и 404 {ok: false, result: null} для отсутствия соли

это меня натолкнуло на мысль что стоит подумать над отсутствием соли. вероятно я измению этот ответ в ближайшем будущем.

к слову, для правильного запроса, по которому должен возвращаться массив. например корзина. в случае отсутствия элементов у меня
200 {ok: true, result: []}

REST API Best Practices

если ендпоинт отсутствует — нефиг отдавать по нему 404

REST API Best Practices

Я фулстек разработчик, с даже бОльшим опытом во фронте. так что я рассматриваю с двух сторон баррикады.

на клиенте нам важно знать получилось ли выполнить операцию или не получилось. получилось — только для статусов 200
всё остальное (и не важно, пропала сеть, неправльный урл, ошибка сервера, ошибка БЛ, да хоть апокалипсис) — это не получилось, тобишь ошибка.

Вы же предлагаете примешать некоторые ошибки к неошибкам что бы вместо одной проверки удалось/неудалось делать их кучу даже в том коде который должен выполняться когда «удалось».

вы заведомо пытаетесь усложнить код. усложнить состояние приложение. ввести ситуации когда у нас есть не только fail/success а ещё и «какбы success, но немножко fail»

REST API Best Practices

Ошибка бизнесс-логики — это ошибка сервера. То что вы её аккуратно отлавливаете — не значит что она не происходила.

REST API Best Practices

ого. большое спасибо! Ваш комментарий был для меня на порядок полезнее статьи (:

REST API Best Practices

ошибки бизнесс-логики — это 500 ошибки.

REST API Best Practices

нет. ошибки должны быть ошибками

REST API Best Practices

8) забыли про 500х коды. И вообще про коды тут пункт ниочём. список HTTP статусов можно и на википедии посмотреть.
Мой бестпрактис касательно кодов: В самой первой версии апи сделайте поддержку 4х статусов

• 200 — ок
• 400 — неправильный запрос
• 404 — не найдено результатов
• 500 — внутренняя ошибка сервера
  Этого достаточно на первое время, а если у вас есть бюджет вы всегда сможете расширить этот список. Главное — поддержать хотя бы их.

5) пагинация через link — имхо это даже бэд практис в некоторых случаях. Если мы предоставляем limit/offset (skip/size и т.п.) — то этого более чем достаточно для пагинации, и создание линков усложняет код, не привнося никакого дополнительного функционала (ведь пагинация и так есть). А вот отказываться от limit/offset в пользу линков — плохая идея. мы заведомо ограничиваем возможности клиента, не привнося ничего взамен.

7) А что за путаница у него в методах и их индепендности? и счего бы вдруг GET был индепендным? запросив одну и ту же книгу с разницей в несколько секунд, у неё может измениться статус или рейтинг. Но это уже мелочь

Валидация строк с validate.it.js

Думаю этот спор всё-равно ни к чему не приведёт, но я не вижу тут оверхеда...

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

Объект создаётся только потому что с ним работать удобнее. В нём не лежит ни одной функции, и он легко сериализуется в JSON. Все ассерты находятся в прототипе который JS движок не будет пересоздавать на каждый чих.

Да, функциональщина это круто. Но тут получается функциональщина ради функциональщины.

Кроме этого, если оформить в функциональном стиле, мы получим ...

… усложнение кода библиотеки, повышение порога вход, усложнение кода клиента и стоимости его поддержки, без выйгрыша в чём либо.
Теоретически compose вместе с хитрым createComplexRule могут дать какой-то прирост в производительности по сравнению с runAssertAsMethod. Но это уж точно выглядит оверхедом и преждевременной оптимизацией

Валидация строк с validate.it.js

можно как-то более развёрнуто?

Валидация строк с validate.it.js

а чем плох:

const validatePassword = pass => validate(pass)
  .hasLettersLatin()
  .hasNumbers();

validatePassword(password1);
validatePassword(password2);

Валидация строк с validate.it.js

нет. неожиданный кейс… но впринципе это легко реализуемо уже на клиенте проверкой кол-ва ошибок

validate(string)
   .rule1()
   .rule2()
   .rule3()
   .rule4()
   .errors.length < 2;

Как организовать парковку за 5 часов по методу определения критического пути CPM?

Ниочём.
Вся статья сплошная вода, которая сокращается до одной фразы "используйте диаграммы Ганта". Настоящее откровение для любого ПМ.

Обозначили пример, а СРМ для него так и не применили даже.

Кодинг без клавиатуры: создание игры hands-free

Вроде бы должно как-то мотивировать. Но лично у меня очень печальные выводы — если я потеряю руки — программистом мне больше не быть.

Роботы для удаленной работы: технические детали и применение

Ну и норм. На 20 минут в курилку с ребятами слетать, а остальное время на рабочем месте в докстанции.

Slack — это противоположность организационной памяти

У дядьки бомбит, потому что он не умеет пользоваться IM, путая их с ERP и офисными пакетами.

дело не в инструментах а в людях!

Если коллеги в чате #mainProject-dev постят котиков — они бы и в почте их всем рассылали и в gDoc вставляли.

Он просто работает с неадекватами, а винит в этом инструменты (:

JavaScript-прокси: и красиво, и полезно

эх, не подошло…

JavaScript-прокси: и красиво, и полезно

Другое (в комментариях)

Ещё вчера не использовал, но для сегодняшней задачки должно подойти как нельзя лучше.

Почему вам должно быть скучно на работе

а что делать тем кто ютьюбчик не смотрит и в вк тож не особо?
нам тоже нужна волшебная пилюля

V for Validator

Это как сравнивать голый http.createServer и express. Использование if сохранит вам пару часов в простых случаях, но на реализации комплексных условий вы потратите больше времени.

ValidationReport никак не упрощает валидацию по комплексным условиям.