О стандартах мыслей свежих несколько

Сложности, думаю, с первыми двумя пунктами? Возможно, у меня не хватило слов, выразить это по-человечески, но там все просто. Давайте сначала на бытовых аналогиях, а потом на примерах из ИТ. Возьмем полку, которая крепится к стене. Полка — позволяет организовать различные предметы и как только она появляется, то на ней сразу растет разнообразие. Пусть там лежат хоть мелкие предметы, хоть посуда или книги, что угодно. Но вот сверху, на это разнообразие уже не положишь второй слой предметов, тогда все превратится в срач и пользоваться этим будет уже сложно. Но если взять коробки определенного размера и разложить предметы по ним, то их можно будет класть на полку уже в 2-3 уровня. Это будет конечно менее удобно, чем без коробок, но лучше, чем срач. Тут полка — это стандарт первого уровня, он дает базу для коробок — они формируют стандарт второго уровня, а предметы — это появившееся разнообразие. Стандарт первого уровня более жесткий, чем стандарт второго уровня, ибо мы не можем положить шкаф на полку, но вот полку на шкаф положить можем, т.к. шкаф — стандарт более устойчивый. Так же и с программными системами. Вот есть у нас сервер приложений, который по HTTPS с определенных URL запросов отдает нужные ответы в формате JSON. Мы уже ввели конвенции, закрепили протокол, формат представления данных, клиент-серверный принцип обработки (запрос-ответ). Можно множество обработчиков, объединенных конвенциями в сетевое API. А без стандартов, если бы каждый обработчик представлял данные в разном формате и передавал по разному протоколу, это было бы не API, а полный хаос, т.е. обработчики бы было писать значительно сложнее, а пользоваться этим вообще невозможно. Теперь, хотим создать не просто разнообразие API, а разнообразие пользовательских приложений, которые подключаются к этому API. Тогда нам нужно ввести конвенции на уровне запросов и ответов от приложений к серверу. Например, говорим, что ответ всегда будет JSON хешем {}, а не массивом [] и не одинарным значением. Введем правило, чтобы в ответе были всегда поля ErrorCode, Message и Result, например, вот так {«ErrorCode»:null, «Message»:«Work done», «Result»: {...}}. Закрепим, что каждый вызов должен происходить через POST запрос и клиент присылает серверу в POST-e тоже JSON c полем SessionId. И этот SessionId будет даваться в процессе аутентификации. Для демонстрации нам хватит конвенций. Теперь мы можем написать клиентскую библиотеку, которая будет реализовывать данную конвенцию на 5-и языках программирования и на базе этой библиотеки может появиться разнообразие приложений.