dagrigorev/EvolutionaryAPI

## EvolutionaryAPI
  Часто, разработчики веб сервисов сталкиваются с проблемой, при которой они не имеют полного описания задачи. Например, поставщик данных X
не предоставляет документации или люди не могут договриться между собой. Задача - в срочном порядке спроектировать REST API для клиента.
Решение - сделать хардкод на стороне бэкенда или фронтенда с расчетом на то, что изменний не будет.
  Однако, здесь сразу виден недостаток, при кардинальном изменении требований или внезапном расширении данных всем разработчикам придется
переделать имеющийся код. Возникает вопрос, что сделать, чтобы избежать такой проблемы? Ответ - изначально, при возникновении подобных
ситуаций, использовать принципы эволюционного проектирования.
  Сам принцип гласит, что, на первом этапе происходит формализация требований по задаче "общими словами". Далее, при получении новой информации
по задаче, происходит детализация этих формализаций (программного кода, архитектурных диаграмм и т.д.). И так далее по
мере большей информированности разработчиков.
  Возникает мысль, а почему бы не применить такой же принцип при проектировании REST API? Тогда, если описать такой принцип детальнее, можно
получить следующие принципы эволюционного API:
    - Получаем какое-то описание задачи "общими словами"
    - Создаем исчерпывающие контракты, отражающие полученную информацию (например, контракты, которые содержат поля типа Словарь,
    в которые можно будет, по необходимости добавлять новые поля)
    - Содаем только необходимые методы, работающие с контрактами, созданными на предыдущем шаге
    - Называем такой REST API версией 1.0
    - Клиенты работыют с REST API версии 1.0
    - Получаем новую информацию по задаче
    - Детализируем - расширяем исчерпывающий контракт (добавляем новые поля и методы)
    - Контракт оставляем все еще исчерпывающим
    - Называем новые (детализированные) контракты и методы версией 1.1
    - Клиенты, в новых версиях своей части приложения переходят на версию 1.1
    - повторяем шаги, начиная с шага "Получаем новую информацию по задаче"
    - Наше REST API эвполюционирует

Таким образом, происходит разгрузка и равномерное распределение занятости между всеми разработчиками. Также, снимается проблема синхронизации
между разработчиками при такой "конкурентной работе", так как в каждый момент времени существует API прошлых версий, который можно использовать.
	Часто, разработчики веб сервисов сталкиваются с проблемой, при которой они не имеют полного описания задачи. Например, поставщик данных X
	не предоставляет документации или люди не могут договриться между собой. Задача - в срочном порядке спроектировать REST API для клиента.
	Решение - сделать хардкод на стороне бэкенда или фронтенда с расчетом на то, что изменний не будет.
	Однако, здесь сразу виден недостаток, при кардинальном изменении требований или внезапном расширении данных всем разработчикам придется
	переделать имеющийся код. Возникает вопрос, что сделать, чтобы избежать такой проблемы? Ответ - изначально, при возникновении подобных
	ситуаций, использовать принципы эволюционного проектирования.
	Сам принцип гласит, что, на первом этапе происходит формализация требований по задаче "общими словами". Далее, при получении новой информации
	по задаче, происходит детализация этих формализаций (программного кода, архитектурных диаграмм и т.д.). И так далее по
	мере большей информированности разработчиков.
	Возникает мысль, а почему бы не применить такой же принцип при проектировании REST API? Тогда, если описать такой принцип детальнее, можно
	получить следующие принципы эволюционного API:
	- Получаем какое-то описание задачи "общими словами"
	- Создаем исчерпывающие контракты, отражающие полученную информацию (например, контракты, которые содержат поля типа Словарь,
	в которые можно будет, по необходимости добавлять новые поля)
	- Содаем только необходимые методы, работающие с контрактами, созданными на предыдущем шаге
	- Называем такой REST API версией 1.0
	- Клиенты работыют с REST API версии 1.0
	- Получаем новую информацию по задаче
	- Детализируем - расширяем исчерпывающий контракт (добавляем новые поля и методы)
	- Контракт оставляем все еще исчерпывающим
	- Называем новые (детализированные) контракты и методы версией 1.1
	- Клиенты, в новых версиях своей части приложения переходят на версию 1.1
	- повторяем шаги, начиная с шага "Получаем новую информацию по задаче"
	- Наше REST API эвполюционирует

	Таким образом, происходит разгрузка и равномерное распределение занятости между всеми разработчиками. Также, снимается проблема синхронизации
	между разработчиками при такой "конкурентной работе", так как в каждый момент времени существует API прошлых версий, который можно использовать.