Контракт

Рабочий кейс, делюсь с вами им «с пылу, с жару»

➖➖➖

У меня была простенькая задачка: передавать паспортные данные иностранца.

С виду она реально простая, ведь что может быть проще: пойми какой тип документа у иностранца возвращается, передай в те же поля данные, что передаются в паспорте РФ, только используй новый тип документа.

Контракт

➖➖➖

Какие варианты решения я увидел для решения этой задачи?

1 Можно не трогать текущий контракт и дополнить его новым объектом PassportForeign. КОСТЫЛЬНО.

В этом кейсе сразу возникают вопрос: «А что, если кроме паспорта иностранца появятся еще другие документы? Так-то их более 50 видов». Придется делать длинный и негибкий контракт, интеграции с которым будет тяжело поддерживать.

2 Можно сделать правильно контракт, заменив passportRussia на что-то вменяемое, например, documentType, а там передавать тип документа.

При этом контракт станет максимально универсальным и масштабируемым.

Однако, если так делать, то придется весьма прилично поработать, так как просто так поменять контракт нельзя, потому что мы 100% зацепим других потребителей и все им поломаем. Ведь кроме исправления контракта - надо поднимать версию эндпоинта, а старый помечать, как DEPRICATED.

💡Итогом стал выбор второго варианта решения, не смотря на то, что он более долгий по реализации.

➖➖➖

Что я хочу сказать этим постом?
Когда проектируете контракты, то не забывайте про масштабируемость и не делайте константы, которые могут «выстрелить вам потом в ногу» в будущем.

➖➖➖

А те, кто хочет научится правильно проектировать API и уметь учитывать различные нюансы, то жду вас на курсе:

👉🏻 САЙТ КУРСА 👈🏻
👉🏻 САЙТ КУРСА 👈🏻
👉🏻 САЙТ КУРСА 👈🏻

➖➖➖

образовательная лицензия
No Л035-01298-77/01352304 от 16.08.2024

Начать дискуссию