Comments 14
Как вам удалось уместить столько страсти в обработчики HTTP?
Читается как обычный NIH в маленьком проекте. Если вы единственный разработчик и не нужно убеждать команду выбирать существующее знакомое решение то конечно удобно использовать вот именно что вам лично подходит.
Похоже, что вы, критикуя общепризнанные фреймворки, прикрываясь своим неоправданно легковесным многословием, неявно продвигаете свой личный домашний фреймворк, расширяя их неуправляемый вело-зоопарк ещё одним мутным ручным зверьком, прячущимся поверх net/http. Разве ваши микро-хелперы типа delo.Get и d.Err409Conflict это, де-факто, не скрытый фреймворк, маскирующий свою неявную сложность под видом минимализма, только без встроенной защиты от CSRF/XSS, без валидации Content-Type, без механизмов CORS, без нормального, как в REST, документирования API и без преданного сообщества адептов?
Предлагали похоливарить, так что, не обессудьте 😂.
Нормально вы так накинули. Я даже с ходу не могу понять, от чего отбиваться.
1. Я топлю за голый http/net + обертки.
2. Я видел обработчики, где вообще входящие данные не валидируются. CORS сейчас сложно не юзать, у меня мидлваря для этого. Компромиссы везде! Потому сплю спокойно.
3. REST и API-дока - две разные темы. Здесь критикую только пути "а-ля REST".
Я к тому, что ваш подход интересен и демонстрирует вашу глубокую любовь и понимание net/http, но микро-хелперы вроде delo.Get или d.Err409Conflict по сути создают скрытый фреймворк. Без документации и чётких правил это усложняет понимание кода и расходует время на изучение ваших соглашений вместо работы над бизнес-логикой.
Вы говорите про CORS-мидлвари, но в статье не показана валидация входящих данных, однако без явных проверок есть риск легко пропустить уязвимости. Нормальные фреймворки добавляют защиту по дефолту, типа автоматической обработки sec headers.
Да, REST не идеален, как и всё, что придумано человеком в силу теоремы Гёделя о неполноте, но стандартные пути вроде /users/:id кардинально упрощают жизнь, ибо их легко запихать в Swagger, сделать доки и клиентский SDK.
Так что, если уж пишете свои обёртки, то и документируйте их как публичный API. Прикручивайте Swagger для прозрачности, юзайте готовые либы для валидации. Это сохранит ваш контроль над кодом, но снизит риски. Конечно, ваш бесценный опыт кому-то может и будет полезен, но велосипеды лучше юзать для домашних развлечений.
Согласен. У всех решений есть границы. Я точно не буду двигать собственное как единственное. Валидатор v10 описан неявно в параграфе "входящие данные" - юзается после парсинга. Не наблюдаю сложностей прикрутить swagger, не писал про него. Хотя, пожалуй, в теме про API стоило бы. Тут аргумент, что это будет статья о людях в команде, а не про http-обработчик.
Вижу ключевое "по дефолту". Думаю, что у меня кредо такое "не жить по дефолту". У меня в руках и фронт, и бэк. И разбирался, как сделать синергию.
В статье описываю более подробно как "/users/:id кардинально упрощают жизнь" ;) Если коротко, то не упрощают, а перекидывают головняк на фронтенд - у него запрлата меньше, потому их можно взять больше - "по рублю за пучок".
Скрипткиди тоже попроще жить будет
GET /v1/users/:id- это плохо! в списке запросов инструментов браузера в строке будет показан одинокий нечитабельный айдишник, а полный путь с методом отображается только по дополнительному клику в отдельной вкладке .
так это ж настраивается
Верю, а зачем?! Ну будет /v1/users/123 или /v1/users/58f65b99-7a61-43ca-87f0-d0ae3359728e - реально удобно пользоваться?
Люблю я http, и вот как я его готовлю