Главная проблема REST в том, что REST — это термин, не стандарт, не спецификация, а всего лишь свод соглашений, весьма условных и слабых. Каждый волен пилить свою API как угодно. Сколько копий сломано в спорах о том, как называть маршруты до сущностей, правильно ли включать в маршруты глаголы, как версионировать, должен ли API отражать только взаимодействие с сущностями (CRUD) или может обрабатывать бизнес-операции? Базовый CRUD может написать каждый даже не имея навыков программирования, благо сейчас полно конструкторов API. Но стоит API чуток разрастись, как тут же начинаются проблемы с бизнес-процессами. Например, как сделать API для добавления комментариев? POST /comments? POST /articles/1/comments? COMMENT /articles/1?
Многие возразят, что есть стандарты для реализации REST API вроде Swagger (Open API), JSON:API, OData, HAL, RAML, HATEOAS и т.п. На практике из этих стандартов жизнеспоспобны (на моем опыте) только Open API и RAML. И несмотря на наличие этих стандартов все равно остается проблема общения с потребителями API (клиенты, фронтендеры). В лучшем случае у потребителя будет HTML-документация (счастье, если не устаревшая).
Коммент получился сумбурный, но что я хочу сказать из своего опыта — REST хорош для начала как MVP или как публичное API чисто для фронта, потому что можно пользоваться всеми фичами HTTP. Для чего-то серьезного рекомендую применять GraphQL, не потому что он хороший, а потому что на данный момент достойных альтернатив нет.
Будь эта статья написана более спокойным и техническим языком, я бы даже прочитал её. Сейчас статья больше напоминает рекламный буклет, где эффективный продаван пытается продать мне ручку.
С разморозкой. На дворе 2020 год. Все люди пользуются PSR-7 https://www.php-fig.org/psr/psr-7/. И вам советую, раз уж знаете про composer, потрудитесь поискать готовые библиотеки, а не писать велосипеды.
Отличная статья, читал на одном дыхании. Пишите ещё! Единственное что не понял это функция toSoldier. Функция принимает на вход некий self, а в маппере передаёте ей школьника. Как компилятор вывел из него имя?
Итого в сухом остатке активно поддерживаемых языков для .NET осталось только два: C# и F#. А учитывая костыльность применения библиотек в F# (интероп с ООП-шными мутабельными классами похоже на натягивание совы на глобус), остаётся только один православный C#. А ведь когда-то была Scala…
Думаю квадратный метр солнечной панели на порядок дороже, чем отполированний лист стали. Листы стали к тому же легче мыть и не подвержены деградации. Так что у солнечной башни стоимость по крайней мере возведения и содержания всяко дешевле, чем у солнечных панелей.
Рекомендую к прочтению https://github.com/nodkz/conf-talks. Идея в том, что надо использовать свои типы-ошибки для возврата бизнесовых ошибок через Union. Стандартный errors использовать только для технических ошибок (500-ые)
Лучше JSON заменить на что-нибудь вроде MessagePack или CBOR, а это так копейки.
Главная проблема REST в том, что REST — это термин, не стандарт, не спецификация, а всего лишь свод соглашений, весьма условных и слабых. Каждый волен пилить свою API как угодно. Сколько копий сломано в спорах о том, как называть маршруты до сущностей, правильно ли включать в маршруты глаголы, как версионировать, должен ли API отражать только взаимодействие с сущностями (CRUD) или может обрабатывать бизнес-операции? Базовый CRUD может написать каждый даже не имея навыков программирования, благо сейчас полно конструкторов API. Но стоит API чуток разрастись, как тут же начинаются проблемы с бизнес-процессами. Например, как сделать API для добавления комментариев?
POST /comments?POST /articles/1/comments?COMMENT /articles/1?Многие возразят, что есть стандарты для реализации REST API вроде Swagger (Open API), JSON:API, OData, HAL, RAML, HATEOAS и т.п. На практике из этих стандартов жизнеспоспобны (на моем опыте) только Open API и RAML. И несмотря на наличие этих стандартов все равно остается проблема общения с потребителями API (клиенты, фронтендеры). В лучшем случае у потребителя будет HTML-документация (счастье, если не устаревшая).
Коммент получился сумбурный, но что я хочу сказать из своего опыта — REST хорош для начала как MVP или как публичное API чисто для фронта, потому что можно пользоваться всеми фичами HTTP. Для чего-то серьезного рекомендую применять GraphQL, не потому что он хороший, а потому что на данный момент достойных альтернатив нет.
Вы такси придумали
rust-analyzerпока плохо справляется сawait. Выдаетunknown, если используется конструкция видаFuture<Output = T>.С разморозкой. На дворе 2020 год. Все люди пользуются PSR-7 https://www.php-fig.org/psr/psr-7/. И вам советую, раз уж знаете про composer, потрудитесь поискать готовые библиотеки, а не писать велосипеды.
Отличная статья, читал на одном дыхании. Пишите ещё! Единственное что не понял это функция
toSoldier. Функция принимает на вход некийself, а в маппере передаёте ей школьника. Как компилятор вывел из него имя?Поиск датчиков по их значениям напоминает работу с ArtMoney ))
Краткий пересказ статьи:
У эффективных станций тоже стоят моторы под каждой солнечной панелью.
Рекомендую к прочтению https://github.com/nodkz/conf-talks. Идея в том, что надо использовать свои типы-ошибки для возврата бизнесовых ошибок через Union. Стандартный errors использовать только для технических ошибок (500-ые)
Не можешь победить — возглавь
Заботится о лишних тактах процессора. Ставит Windows 10. Логика.