Wewnętrzna i zewnętrzna architektura API

Firma, dla której pracuję, utrzymuje udany produkt SaaS, który z biegiem lat rozwijał się „organicznie”. Planujemy rozszerzyć linię o pakiet nowych produktów, które będą dzielić dane z istniejącym produktem. Aby to wesprzeć, chcemy skonsolidować logikę biznesową w jednym miejscu: warstwie usług internetowych. Warstwa WS będzie używana przez:

• Aplikacje internetowe
• Narzędzie do importowania danych
• Narzędzie do integracji z innym oprogramowaniem klienckim (nie API jako takim)

Chcemy również stworzyć interfejs API, który może być używany przez naszych klientów, którzy mogą go używać do tworzenia własnych integracji. Zmagamy się z następującym pytaniem:

Czy wewnętrzny interfejs API (zwany również warstwą WS) i zewnętrzny interfejs API powinny być takie same, z ustawieniami zabezpieczeń i uprawnień do kontrolowania tego, co może zrobić osoba, lub powinny to być dwie oddzielne aplikacje, w których zewnętrzny interfejs API po prostu wywołuje wewnętrzny interfejs API jak każda inna aplikacja? Jak dotąd w naszej debacie wydaje się, że ich rozdzielenie może być bezpieczniejsze, ale spowoduje dodatkowe obciążenie.

Co zrobili inni w podobnej sytuacji?

Zawsze dobrze jest jeść własne psie pożywienie. Jeden interfejs API powinien być również prostszy w utrzymaniu niż dwa, nawet jeśli weźmiesz pod uwagę pewne koszty ogólne związane z uwierzytelnianiem i autoryzacją.

Chociaż zgadzam się z Aneurysm9, czasami nie chcesz ujawniać wszystkich możliwości swojego systemu. W takim przypadku preferowane byłoby posiadanie dwóch interfejsów API ... ALE jeśli to zrobisz, wybierz ten sposób ... upewnij się, że wszystkie typowe funkcje współużytkują ten sam interfejs API, tj. Jeden z nich jest rozszerzoną wersją drugiego, a nie dwoma odrębnymi zestawy kodu.

W ten sposób możesz używać własnego dla siebie, mając jednocześnie miejsce na prywatne, wrażliwe, eksperymentalne prace, jednocześnie umożliwiając publikowanie i używanie nowych rzeczy bez zbytniej zmiany publicznego interfejsu API.

Zetknąłem się z tym wcześniej (wiele razy) i wolałem:

Wyjmij BL ze strony internetowej. Ustaw witrynę jako konsumenta interfejsu API. Traktuj witrynę jak zwykłego klienta API. Twój interfejs API to usługa.

Jeśli uważasz, że potrzebujesz specjalnych metod API tylko dla witryny, pomyśl jeszcze raz! Jeśli jest dobry dla gęsi, jest dobry dla wędrowca. Jeśli naprawdę naprawdę potrzebujesz specjalnej funkcjonalności dla witryny, sugerowałbym, że to, co naprawdę znalazłeś, stanowi różnicę w „profilu użytkownika” i dlatego jest to sytuacja, w której API powinien nadal obsługiwać „specjalne” funkcje, ale wtedy kontrolować je poprzez autoryzację.

Nieprzekonany?

Zrób paradygmat o krok dalej ...

Aplikacja na telefon działa na platformie, na której wykonywany jest kod bajtowy, aplikacja mieszka w telefonie i zużywa usługi API przez HTTP / JSON

Witryna to aplikacja działająca na platformie, na której wykonywany jest HTML + JavaScript, aplikacja działa w przeglądarce i korzysta z usług API przez HTTP / JSON

Takie samo!

Rozszerz to na tablety, telewizory, inne platformy telefoniczne, wtyczki, aplikacje innych firm, mashupy, ...

Wiele różnych doświadczeń użytkownika podłączonych do wspólnego API.

Twoja aplikacja jest interfejsem API. Witryna jest tylko jednym klientem (spośród wielu)

Użyj jednego interfejsu API

Jeśli implementujesz interfejs API usługi jako warstwę REST, po prostu dodaj uwierzytelnianie do chronionych tras.

Prawdopodobnie zechcesz użyć frameworka programistycznego, który nie upiecze zbyt wiele „magii”. Coś, w którym możesz bezpośrednio definiować trasy bez całej rekonstrukcji.

Pomyśl coś takiego jak Node.js / Express, python / pylons, silnik aplikacji python / google itp.

Niedawno zaimplementowałem to w Google App Engine dla interfejsu API REST / Datastore i nie sądzę, żeby mogło być łatwiej. Kontrolery są implementowane jako klasy, a ich kolejne żądania HTTP (tj. GET / POST / PUT / DELETE) są implementowane jako metody tych klas. Udało mi się zaimplementować basic-auth jako dekorator. To spowodowało, że dodanie wymogu uwierzytelnienia do żądania było tak proste, jak dołączenie dekoratora @basicAuth.

W ten sposób mogłem upublicznić przychodzące żądania GET, dodając wymóg uwierzytelnienia do żądań POST / PUT / DELETE na tym samym kontrolerze dla tego modelu.

Jeśli wiesz, jak mówić w REST, życie staje się o wiele łatwiejsze, ponieważ obsługa REST jest już nieodłącznie zapisana w dowolnym serwerze internetowym (tj. HTTP jest tylko rodzajem interfejsu API REST). Możesz nawet wybrać przezroczystą kompresję gzip, jeśli wysyłasz dużo danych przez drut.

Moje pierwsze wrażenie jest takie, że powinien to być ten sam interfejs API i że twoje zabezpieczenia powinny znajdować się na innej warstwie. Może obsługiwany przez front internetowy?