Projektowanie REST API dla interoperacyjności systemów C2 NATO

System dowodzenia i kierowania, który nie może dzielić się swoim obrazem operacyjnym z partnerami koalicyjnymi, jest narodowym silosem, a nie zdolnością koalicyjną. W miarę jak NATO przechodzi ku architekturom zorientowanym na usługi, REST API stało się praktycznym interfejsem do wymiany ustrukturyzowanych informacji C2 między systemami narodowymi przez sieci IP. Lecz samo REST API niczego nie gwarantuje: interoperacyjność wynika ze schematu, który API udostępnia, a nie z faktu, że posługuje się ono HTTP. Ten przewodnik prowadzi przez decyzje projektowe, które czynią REST API systemu C2 rzeczywiście interoperacyjnym w obrębie koalicji NATO.

Dlaczego REST API dla interoperacyjności C2

Przez dekady interoperacyjność koalicyjna oznaczała taktyczne łącza danych punkt-punkt — Link 16, VMF, Link 22 — z których każde było własną, sprzężoną ze sprzętem integracją. Te łącza pozostają niezbędne na obrzeżu taktycznym, lecz nie skalują się do interakcji żądanie-odpowiedź, obfitujących w zapytania, na szczeblu dowództwa i operacyjnym. Pobieranie struktury sił, wysyłanie zadania, pobieranie nakładki mapy czy subskrybowanie aktualizacji obiektów to interakcje usług sieciowych, a nie rozgłoszeniowe komunikaty taktyczne.

Przejście NATO ku architekturze zorientowanej na usługi to odzwierciedla. Ramy Federated Mission Networking traktują zdolności C2 jako usługi z udokumentowanymi interfejsami, wykrywalne przez rejestr, zabezpieczone tożsamością federacyjną. REST — zorientowany na zasoby, bezstanowy, buforowalny, zbudowany na wszechobecnym oprzyrządowaniu HTTP — naturalnie pasuje do tego modelu. Partner koalicyjny, który potrafi wysłać żądanie HTTPS, może korzystać z usługi REST bez specjalistycznego sprzętu.

REST nie jest jednak zamiennikiem łączy opartych na komunikatach. Czasoszczelinowe, niskoopóźnieniowe rozgłaszanie Link 16 jest niezastąpione dla szybkiej dystrybucji danych taktycznych; VMF przenosi sformatowane komunikaty naziemne przez ograniczone nośniki. Osąd inżynierski polega na dopasowaniu transportu do interakcji: taktyczne łącza danych do dystrybucji maszyna-maszyna, krytycznej czasowo na obrzeżu; REST do ustrukturyzowanych produktów informacyjnych wymienianych między systemami połączonymi przez IP. Większość rzeczywistych architektur uruchamia oba, z bramą łączącą domenę taktyczną i zorientowaną na usługi. Szerszy krajobraz standardów opisujemy w naszym kompletnym przewodniku po interoperacyjności NATO.

Modelowanie zasobów dla domen wojskowych

Pierwszym zadaniem projektowym jest identyfikacja encji domenowych, które udostępnia API, i zamodelowanie ich jako zasobów REST. Obraz operacyjny C2 naturalnie rozkłada się na obiekty, jednostki, zadania, rozkazy i nakładki — każde będące zasobem o stabilnej tożsamości i jasnym URI. Obiekty mieszczą się pod /tracks i /tracks/{id}; jednostki pod /units/{id}; rozkazy i ich zadania pod /orders/{id}; nakładki graficzne pod /overlays/{id}. Dane referencyjne — katalogi symboli, układy współrzędnych — mają własne stabilne punkty końcowe.

Rozróżnienie kolekcja-vs-element kieruje projektowaniem zapytań. Punkt końcowy kolekcji taki jak /tracks obsługuje filtrowanie dla typowych wzorców dostępu: przestrzenny prostokąt ograniczający (?bbox=…), okno czasowe (?since=…), pułap klasyfikacji, przynależność do jednostki. Punkt końcowy elementu zwraca pełną reprezentację pojedynczego zasobu. Relacje — obiekt należy do jednostki, rozkaz odwołuje się do zadań — są reprezentowane przez osadzanie lub łączenie, co jest świadomym kompromisem między liczbą obrotów a rozmiarem ładunku.

Punkt decydujący: model zasobów to wybór projektanta API, lecz reprezentacja wewnątrz każdego zasobu już nie. Ładunek powinien mapować się na model wymiany informacji MIP4 (IEDM), model danych NATO dla naziemnego obrazu operacyjnego, a nie na wymyśloną wewnętrzną strukturę. Czyste projektowanie URI udostępniające własny JSON nie jest interoperacyjne z nikim; czyste projektowanie URI udostępniające ładunki zgodne z MIP4 jest konsumowalne przez każdego partnera wdrażającego MIP4.

Zgodność ze standardami danych NATO

Zgodność ze standardami zachodzi na poziomie schematu ładunku, więc każda reprezentacja zasobu musi mapować się na model zdefiniowany przez STANAG. Ustrukturyzowane dane obrazu operacyjnego — obiekty, jednostki, rozkazy — mapują się na MIP4 IEDM. Grafika taktyczna i nakładki mapują się na NATO Vector Graphics (NVG). Sformatowane komunikaty operacyjne mapują się na katalogi komunikatów ADatP-3 / APP-11. Mapowanie jest pracą integracyjną: wewnętrzny model danych API jest tłumaczony, pole po polu, na schemat standardowy na wyjściu i analizowany z powrotem na wejściu.

Negocjacja treści pozwala pojedynczemu zasobowi udostępniać wiele reprezentacji klientom o różnych możliwościach. Zasób nakładki może zwracać application/vnd.nvg+xml dla klienta świadomego NVG; kolekcja obiektów może zwracać reprezentację MIP4 lub GeoJSON w zależności od nagłówka Accept. Utrzymuje to model zasobów stabilnym, jednocześnie uwzględniając heterogeniczne łańcuchy narzędzi koalicji.

Walidacja schematu czyni zgodność rzeczywistą, a nie deklaratywną. Zarówno ładunki żądań, jak i odpowiedzi są walidowane wobec opublikowanych schematów NATO na granicy API, a ładunki niezgodne są od razu odrzucane. Bez wymuszonej walidacji wkrada się dryf schematu — pominięte pole opcjonalne tu, rozszerzona lista kodów tam — i API po cichu odchyla się od standardu, aż zawodzi w interoperacyjności z partnerem dokładnie w najgorszym momencie. Ścisła walidacja na granicy to tania polisa przeciw kosztownym awariom integracji.

Bezpieczeństwo i klasyfikacja w warstwie API

Koalicyjne dane C2 są klasyfikowane i opatrzone zastrzeżeniami, a to warstwa API jest miejscem, gdzie te kontrole są egzekwowane — nie interfejs użytkownika. Każda reprezentacja zasobu niesie etykietę poufności STANAG 4774 określającą poziom klasyfikacji (na przykład NATO SECRET) oraz jego zastrzeżenia dotyczące udostępniania (REL TO nazwanemu zestawowi narodów). Etykieta jest kryptograficznie powiązana z danymi zgodnie ze STANAG 4778, tak że nie można jej oddzielić od treści ani zmienić w tranzycie.

Warstwa kontroli dostępu ocenia żądającego względem etykiety każdego zasobu przed zwróceniem czegokolwiek. Zapytanie kolekcji nie zwraca każdego pasującego obiektu; zwraca tylko te obiekty, których etykietę żądający ma poświadczenia i upoważnienie narodowe zobaczyć, filtrując odpowiedź do podzbioru udostępnialnego. Ta ocena dla każdego zasobu wykonuje się przy każdym żądaniu, a każda decyzja dostępu jest rejestrowana do celów audytu.

Bezpieczeństwo transportu to wzajemny TLS — zarówno klient, jak i serwer przedstawiają certyfikaty — więc tożsamość systemu wywołującego jest ustanawiana kryptograficznie. Tożsamość federacyjna użytkownika wywołującego jest ustanawiana przez OAuth2/OIDC, gdzie API jest skonfigurowane do przyjmowania tokenów wydanych przez dostawców tożsamości partnerów koalicyjnych we wdrożeniu Federated Mission Networking. Ten model zaufania federacyjnego pozwala operatorowi narodu partnerskiego uwierzytelnić się wobec usługi innego narodu bez współdzielonego katalogu użytkowników. Podstawy RBAC i wzorce silnika polityk omawiamy w naszym przewodniku brama API dla koalicyjnego współdzielenia danych.

Wersjonowanie i wsteczna kompatybilność

Koalicyjne API C2 ma wielu konsumentów i nie aktualizują się oni równocześnie. Wersjonowanie nie jest zatem opcjonalnym wykończeniem — to ono utrzymuje systemy partnerów sprawnymi podczas ewolucji API. Dwie powszechne strategie to wersjonowanie URI (/v2/tracks), które jest jawne i przyjazne buforowaniu, oraz negocjacja oparta na nagłówku (wersja w nagłówku Accept), która utrzymuje URI stabilnymi. Pragmatyczna kombinacja używa głównych wersji opartych na URI dla zmian łamiących i negocjacji nagłówka dla drobnej, wstecznie kompatybilnej ewolucji.

Ewolucja schematu musi być zdyscyplinowana, ponieważ ładunki śledzą zewnętrzne standardy NATO, które same się wersjonują. Dodawanie pól opcjonalnych jest wstecznie kompatybilne; usuwanie pól, zmiana ich nazw czy zacieśnianie walidacji jest łamiące i wymaga nowej głównej wersji. API musi mapować między wersjami schematów MIP4 lub NVG wdrażanymi przez różnych partnerów, co oznacza wspieranie więcej niż jednej wersji schematu jednocześnie podczas okien przejściowych.

Dla systemu wielonarodowego oznacza to opublikowaną politykę wycofywania: jak długo wspierana jest wycofywana wersja, jak partnerzy są powiadamiani i jak koordynowane jest przejście. Usunięcie wersji, od której partner koalicyjny wciąż zależy, jest incydentem operacyjnym, a nie rutynowym porządkowaniem. Dyscyplina polega na traktowaniu każdej zmiany łamiącej jako wieloletniej migracji dotyczącej suwerennych programów partnerów i planowaniu wycofań wobec ich cykli aktualizacji, a nie twojego tempa wydań.

NATO Vector Graphics i nakładki taktyczne przez REST

NATO Vector Graphics (NVG) to standaryzowany przez STANAG format XML do wymiany graficznego wspólnego obrazu operacyjnego — symboli wojskowych, taktycznych środków kierowania, obszarów, tras — między systemami narodowymi C2. NVG najnaturalniej udostępniane jest jako usługa REST: klient żąda nakładki z punktu końcowego takiego jak /nvg/{overlay} i otrzymuje dokument NVG XML, którego elementy niosą pozycje, kody symboli APP-6 / MIL-STD-2525 i metadane.

Symbolika czyni NVG interoperacyjnym: ponieważ każda grafika niesie standardowy kod symbolu APP-6 lub MIL-STD-2525, system odbierający renderuje nakładkę partnera własną biblioteką symboli, a operator widzi poprawny, znajomy obraz. Nie ma negocjacji co do znaczenia symbolu; standard to ustala.

Przepustowość na łączach koalicyjnych jest ograniczona, więc wzorce aktualizacji mają znaczenie. Naiwny klient ponownie pobiera całą nakładkę według czasomierza; dobrze zaprojektowana usługa NVG obsługuje aktualizacje przyrostowe, zwracając tylko elementy zmienione od ostatniego odpytania klienta. Wybór między odpytywaniem a strumieniowaniem to rzeczywista decyzja architektoniczna: odpytywanie jest proste i przyjazne zaporom, lecz wymienia opóźnienie na narzut żądań, podczas gdy strumieniowanie serwerowe daje niższe opóźnienie kosztem podtrzymywanych połączeń, których niektóre granice sieci koalicyjnych zabraniają. Dla większości wdrożeń NVG przyrostowe odpytywanie w rozsądnym interwale jest pragmatycznym domyślnym wyborem. Szerszą integrację FMN omawiamy w naszym przewodniku wdrożeniowym Federated Mission Networking.

Droga do walidacji FMN i CWIX

API jest interoperacyjne, gdy system partnera faktycznie z niego korzysta podczas testów, a nie gdy jego projektant uważa schemat za poprawny. Federated Mission Networking definiuje wymagania usługowe: dla każdego obszaru zdolności FMN Spiral określa obowiązkowy profil interfejsu usługi, który zgodna usługa musi wdrożyć. API obrazu operacyjnego zwykle wdraża usługę NVG dla grafiki i usługę zgodną z MIP4 dla danych ustrukturyzowanych, stosuje etykietowanie STANAG 4774/4778, obsługuje wymagane mechanizmy wzajemnego TLS i tożsamości federacyjnej oraz rejestruje się w federacyjnym rejestrze usług, aby partnerzy mogli ją odnaleźć.

Rejestr usług sprawia, że środowisko federacyjne działa: zamiast zakodowanych na stałe punktów końcowych partnerów, każdy naród publikuje swoje usługi do rejestru, a konsumenci dynamicznie je odnajdują i wiążą. To architektoniczne przejście od integracji punkt-punkt do prawdziwej federacji.

Zgodność jest dowodzona na CWIX, dorocznych ćwiczeniach Coalition Warrior Interoperability eXercise, gdzie usługa jest testowana na żywo wobec implementacji partnerów. Zdyscyplinowana droga to walidacja wobec referencyjnych implementacji partnerów przed CWIX, aby niejednoznaczności — inaczej zinterpretowane pole opcjonalne, przypadek brzegowy listy kodów — były rozwiązywane w tanim miejscu, a nie odkrywane na ćwiczeniach. Udokumentowanie, który profil FMN Spiral, które wersje STANAG i które wersje schematów wdraża API, jest częścią pakietu akredytacyjnego i podstawą dowodową dla zamówień.