Внутрішня та зовнішня архітектура API

Компанія, над якою працюю, підтримує успішний продукт SaaS, який росло "органічно" протягом багатьох років. Ми плануємо розширити лінійку набором нових продуктів, які будуть обмінюватися даними з існуючим продуктом. Щоб підтримати це, ми прагнемо об'єднати бізнес-логіку в єдине місце: рівень веб-сервісу. Шар WS буде використовуватися:

• Веб-додатки
• Інструмент для імпорту даних
• Інструмент для інтеграції з іншим клієнтським програмним забезпеченням (не API)

Ми також хочемо створити API, який може бути використаний нашими клієнтами, які здатні використовувати його для створення власних інтеграцій. Ми боремося з наступним питанням:

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

Що зробили інші у подібній ситуації?

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

Хоча я згоден з Aneurysm9, іноді ви не хочете розкривати всі можливості вашої системи. У цьому випадку краще мати два API ... Але якщо ви вибрали такий спосіб ... переконайтесь, що всі загальні функціональні можливості мають один і той же API, тобто, щоб одна була розширеною версією іншого, а не двома різними набори коду.

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

Я з цим стикався раніше (багато разів), і те, що в кінцевому підсумку я віддаю перевагу:

Візьміть BL з веб-сайту. Зробіть веб-сайт споживачем API. Ставтесь до веб-сайту як до іншого клієнта вашого API. Ваш API - це послуга.

Якщо ви думаєте, що вам потрібні спеціальні методи API лише для веб-сайту, подумайте ще раз! Якщо це добре для гусака, це добре для ґендера. Якщо вам дуже потрібна спеціальна функціональність для веб-сайту, я б підказав, що те, що ви насправді знайшли, є різницею в "профілі користувача", і тому це ситуація, коли API все ж повинен підтримувати "спеціальні" функції, але тоді ви контролювати їх за допомогою авторизації.

Не переконані?

Зробіть парадигму на крок далі ...

Додаток телефону працює на платформі, де виконується байт-код, програма живе в телефоні та споживає послуги API через HTTP / JSON

Веб-сайт - це додаток, який працює на платформі, де виконується HTML + Javascript, програма живе у браузері та споживає послуги API через HTTP / JSON

Те саме!

Розширте це на планшети, телевізори, інші телефонні платформи, плагіни, додатки сторонніх розробників, мачупи, ...

Дуже багато різноманітних користувачів, які підключаються до загального API.

Ваш додаток - це API. Веб-сайт лише один клієнт (з багатьох)

Використовуйте один API

Якщо ви реалізуєте сервісний API як рівень REST, просто додайте автентифікацію до захищених маршрутів.

Ймовірно, ви хочете використовувати рамку розробки, яка не випікається в надто великій кількості "магії". Щось, де ви можете безпосередньо визначати маршрути без усієї серії зворотних інженерій.

Подумайте щось на зразок Node.js / Express, python / pylons, двигуна додатків python / google тощо.

Нещодавно я реалізував це в Google App Engine для API REST / Datastore, і не думаю, що це могло бути простіше. Контролери реалізуються як класи, а їх наступні HTTP-запити (тобто GET / POST / PUT / DELETE) реалізуються як методи цих класів. Мені вдалося реалізувати basic-auth як декоратор. Це зробило додавання вимоги до аутентифікації до запиту таким же простим, як прикріплення декоратора @basicAuth.

Таким чином, я можу зробити вхідні GET-запити загальнодоступними додати вимогу аутентифікації до запитів POST / PUT / DELETE на тому ж контролері для цієї моделі.

Якщо ви знаєте, як розмовляти в REST, життя стає набагато простішим, оскільки підтримка REST вже по суті задіяна у будь-якому веб-сервері (тобто HTTP - це лише тип REST API). Можна навіть вибрати прозоре стиснення gzip, якщо ви надсилаєте багато даних по всьому каналу.

Моє перше враження, що це повинен бути той самий API, і що ваша безпека взагалі повинна бути на іншому шарі. Можливо, обробляється веб-фронтом?