Дополнение к статье про проектирование REST-интерфейсов и предтеча статьи про проектирование асинхронных интеграций. Короткая статья про отношение к интерфейсу как к чему-то, что касается более чем одной информационной системы и существует продолжительное время.
Дословно, закон Джона Постела звучит так:
Консервативно относитесь к своей деятельности и либерально - ко вкладам других.
Я бы сказал, что закон Постела является упращением интеграционных паттернов DDD, но он лаконичен и полезен сам по себе.
Будьте консервативны в части сервиса, который вы предоставляете.
Помните, что вы решаете конкретную задачу под конкретные требования. Если у вас нет веских оснований для выхода за рамки требований, относительно функций интерфейса и предоставляемых данных - не выходите за эти рамки. Почему?
- Усложнение решения паразитными функциями, которые надо поддерживать.
- Размытие знаний, которые повысят lead time при развитии интерфейса в дальнейшем. Ведь требования != архитектура и решение..
- Неявное повышение связанности. Ваш контракт могут использовать не так как вы ожидаете.
Будьте либеральны к тому, какой сервис предоставляется вам.
Ваше восприятия контракта предоставляемого вам - это ваше восприятие и оно может ограничиваться только согласованными требованиями.
Не создавайте дополнительных точек сцепления, не потребляйте данных, которые вам не нужны или которые у вас и так есть.
Звучит глупо и/или очевидно? А вот и нет, часто разработчики и даже архитекторы пренебрегают формализацией или контролем data-flow в решении и каким образом данные обновляются или модифицируются, может быть большой неожиданностью.
Используйте версионирование при разрыве контракта.
Это работает в обе стороны.
Внимательно относитесь к обратной совместимости спецификаций, в частности и катаракта в общем. И чем внимательнее вы относитесь к специфичности своего интерфейса, тем меньше проблем с совместимостью у вас будет. Это же касается и определения точки несовместимости с предидущей версией.
Что касается, обратного действия, вас как потребителя сервиса, должно насторожить отсутствие версионирования, ну фактически, у любого интерфейса, здесь либеральный подход не очень подходит. Здесь, имеет смысл принять решение о необходимости презентационного слоя - прокси между интерфейсом и вами, для снижения возможных рисков при изменениях интерфейса провайдера.