Post #762

Смотрим на API, как программисты. В сообществе регулярно возникает вопрос — нужно ли аналитику уметь программировать, и зачем. Покажу пример, как может быть устроена логика мышления например при выборе технологий API, если вы смотрите на них с позиции программиста. Чуть ли не главное понятие в языках программирования — система типов. Всех программистов в университетах мучают понятиями "статическая типизация", "динамическая типизация", "сильная и слабая типизация". Проблемы с типами являются источником большинства ошибок в программах: не учли значение null; складывали числа, а они оказались строками; вышли за пределы массива; думали, что дробная часть отделяется точкой, а в данных была запятая; и т.п. Ну, и все мы сталкивались с превращением всего подряд в дату в Excel. А система типов, по одному из определений — синтаксический разрешимый метод доказательства отсутствия определенного поведения программы. Это уже большой успех, потому что вообще говоря вычислить наличие или отсутствия какого-то свойства у программы невозможно — это математически доказано, называется теорема Райса. Проблема настолько концептуальная, что есть целая математическая теория типов и довольно сложные в понимании модели лямбда-исчислений, лямбда-кубы и прочая функциональщина. Функциональные языки и стали популярны отчасти из-за того, что правильность их программ в некоторых случаях можно доказать. Запросы и ответы HTTP API по умолчанию вообще никак не типизированы. Это просто строки. Соответственно, REST API сам по себе тоже не типизирован. По крайней мере Филдинг ничего про это не писал. Он писал только про media types, на уровне всего ответа целиком, а не отдельных его полей. Это всё в русле JavaScript — динамически-типизируемого и слабо-типизированного языка. Погуглите ради интереса "JavaScript memes" — они все про преобразование типов 😹 Но на клиентах это создает бооольшую проблему — фактически, заставляет писать код в "защитном стиле", подразумевая, что снаружи может прийти вообще всё, что угодно. Адовая работа. Гораздо проще использовать типобезопасные (typesafe) языки и технологии — с указанием конкретных типов, их возможных преобразований и отлова ошибок ещё до основной обработки. Поэтому всё, что появилось после REST — было сразу типобезопасно. Собственно, зачем OpenAPI с его схемами? Если генерировать код и клиентов, и сервера из одной спецификации — он будет типобезопасным. GraphQL — сразу типобезопасный, потому что для него вообще первичная схема, всё остальное из неё генерится. Protobuf (и gRPC, соответственно) — сразу типобезопасный, для него тоже первичная схема. Kafka, как и HTTP, по умолчанию вообще не проверяет содержимое сообщения и его формат. Но есть Kafka Schema Registry — хранилище схем сообщений с готовыми клиентами для продюсеров и консьюмеров. И вот эта типобезопасность может быть для разработчиков хорошим аргументом для перехода на что-то дальше REST (а хотя бы и на OpenAPI с генерацией кода). Может ли системный аналитик говорить со своей командой на этом уровне?