Чи варто взагалі розробляти клієнтську бібліотеку для REST-послуг, щоб запобігти злому API?

9

У нас є проект, де код UI буде розроблений тією ж командою, але іншою мовою (Python / Django) з рівня послуг (REST / Java). Код кожного шару залишається в різних сховищах коду і може дотримуватися різних циклів випуску. Я намагаюся розробити процес, який запобіжить / зменшить порушення змін рівня сервісу з точки зору рівня користувальницького інтерфейсу.

Я думав написати інтеграційні тести на рівні шару користувальницького інтерфейсу, які ми будемо виконувати щоразу, коли ми будуємо інтерфейс або рівень послуг (ми використовуємо Дженкінса як наш інструмент CI для створення коду, який знаходиться у двох репортажах Git) і якщо виникають збої, тоді щось на рівні сервісу зламалося, і фіксація не приймається.

Чи було б також хорошою ідеєю (чи це найкраща практика?), Щоб розробник рівня послуг створював і підтримував клієнтську бібліотеку для служби REST, що існує на рівні користувальницького інтерфейсу, яку вони оновлюватимуть кожного разу, коли відбудеться перервна зміна їх сервісний API? Можливо, тоді ми мали б перевагу статичного типу API, на якому створюється код інтерфейсу. Якщо API клієнтської бібліотеки зміниться, код UI не буде компілюватися (тому ми швидше дізнаємось, що відбулася переломна зміна). Також я б ще запустив тести інтеграції після побудови інтерфейсу користувача або рівня сервісу для подальшої перевірки того, що інтеграція між інтерфейсом користувача та сервісами все ще працює.

rest django

— Кращі практики
джерело

6

Чи не повідомляється вам про зміну API? У цих випадках найчастіше найкраще версію API, щоб ваш інтерфейс завжди мав робочу версію. Потім якнайшвидше "оновіть" останню версію API.

— Метт S

@MattS: Я з вами згоден. Але з комунікацією або без неї: зробити оновлення зміненого API набагато простіше, коли компілятор вказує вам точно всі місця, які ви повинні змінити у своєму коді. Незважаючи на те, що ОП все ще не в змозі сказати нам, як його Python код надаватиме статично типовий API.

— Док Браун

1

Загалом, для методів API, які відходять, виберіть конвенцію та 'скасуйте' їх, особливо, як тільки повний, API заміни буде доступний та протестований. Залиште старий API (по суті), але позначте метадані підпису методу або вставте подію реєстрації, щоб використання можна було чітко визначити.

Реєстрація в API сервісу - одне, але попередження споживачів - це інше. Щодо REST, я не думаю, що існує міцна, стандартна практика. Клієнти API FourSquare можуть виявити застарілі методи навіть у випадку успішного виклику (код HTTP 200, однак помилка типу буде встановлено як "застаріла"). Можливо, розумна стратегія надання споживачам можливості пізнати застарілий метод в API, не викликаючи зриву.

https://developer.foursquare.com/overview/responses

В інструкціях щодо API запропонуйте дату або номер випуску версії, де застарілий API буде видалено повністю. Коли ви будете чітко формувати свою стратегію припинення роботи, ви хочете попередити споживачів API про те, що запропонована стратегія (як вони можуть виявити застарілі методи, як перейти на API заміни та коли застарілий API більше не буде доступний, якщо під час очищення API) і вимагайте від них зворотного зв’язку, щоб переконатися, що процес є доброзичливим для всіх.

— JustinC
джерело

1

Версія вашого API - ще одна можливість. Коли нова версія розгорнута, залиште стару версію також активною та дозвольте узгодження через запит. Якщо ви підтримуєте останню 2 або 3 версії, то код інтерфейсу можна оновити власними темпами.

— джиггі
джерело

1

Одразу є щонайменше три питання, давайте зробимо їх по одному

"чи гарна ідея мати клієнтську бібліотеку для служби REST?"

Найімовірніше, так, доки ви не хочете, щоб довільні REST-дзвінки безпосередньо розсипалися по всьому коду вашого інтерфейсу.

"чи гарна ідея дозволити розробнику шару послуг створювати та підтримувати"? "

Це залежить від осіб у вашій команді. Обслуговувач API повинен знати як речі, доступні в рівні послуг, так і вимоги рівня інтерфейсу користувача. Таким чином, це може бути або людина з рівня послуг, або людина з рівня користувальницького інтерфейсу, або (залежно від розміру та інших завдань) людина незалежно від обох команд.

[ми отримаємо перевагу від того, що] "якщо API бібліотеки клієнтів зміниться, код UI не буде компілюватися"

Ви не сказали, що інтерфейс буде записаний на Python? Це не є статично типова мова, тому я не очікував негайного перерви в збірці від зміни API. Я припускаю, що я помилився на даний момент і у вас тут є статично набраний API - тоді ви можете отримати тут деякі переваги, доки збірка не порушиться, лише додаючи до API нові функції (наприклад, нові необов'язкові параметри) . Інакше ви зробите багато непотрібних накладних витрат для своєї команди.

— Док Браун
джерело