Projektowanie interfejsu API dla danych przestrzennych

Zastanawiam się nad stworzeniem interfejsu API, aby udostępnić kolegom do analizy niektóre zbiory danych przestrzennych.

Część mojej pracy polegała na analizie i przygotowaniu danych, które inni mogą następnie wykorzystać do dalszej analizy. Praca (choć obecnie w mniejszej skali i mniej wyrafinowana) jest podobna do walkscore, ale wymaga ogromnych zbiorów danych. Narastają ograniczenia dotyczące sposobu udostępniania oryginalnych danych, ale moją pracę pochodną można udostępniać. Zastanawiałem się, jak najlepiej udostępnić wyniki mojej analizy (poza przekazywaniem dużych zbiorów danych) i pomyślałem, że API byłoby jednym podejściem. O jakich rzeczach powinienem pomyśleć przy tworzeniu interfejsu API? Czy istnieją specyfikacje projektowe, których mogę przestrzegać?

Moja wizja brzmi trochę bardziej okazale niż obecnie, ale myślę, że byłoby to przydatne ramy, które można by rozważyć na początku tej pracy.

Przez API, zakładam, że masz na myśli jakiś dostęp sieciowy do twoich danych poprzez romans typu HTTP POST / GET, taki jak API Google Maps? Czy będą to dane rastrowe czy wektorowe? Zakładam wektor na potrzeby tej dyskusji. To tak naprawdę protokół komunikacyjny, a nie interfejs programowania aplikacji.

Nie musisz projektować niczego od zera, ponieważ istnieje wiele standardowych protokołów (zamiast interfejsów API jako takich, mam trochę problemów z wywoływaniem interfejsów API, gdy nie są, ale nie będę cię nudzić! ). Jeśli chcesz tylko udostępnić swoim klientom dane wektorowe tylko do odczytu, potrzebujesz serwera WFS, który stoi przed bazą danych. W przeszłości korzystałem z GeoServer , ale wolę lekkość TinyOWS . Oba wykonują to samo zadanie: skonfiguruj je, aby uzyskać dostęp do bazy danych danych pochodnych, ustaw je jako część serwera WWW ( Apache jest powszechny, ale wolę lighttpd) i masz to. QGIS może ładować dane z serwera WFS i bez wątpienia może to zrobić Arc. OpenLayers ma również możliwości renderowania WFS dla rozwiązania opartego na przeglądarce. Na niższym poziomie GDAL może być używany do konwersji danych z WFS do dowolnego formatu wektorowego obsługiwanego przez OGR.

Jeśli chcesz możliwości edycji, zarówno GeoServer, jak i TinyOWS obsługują WFS-T, umożliwiając użytkownikom przesyłanie analiz z powrotem na twój serwer.

Stworzenie własnego interfejsu API naprawdę nie pozwala na osiągnięcie tych standardów w pierwszej kolejności, chyba że jesteś niewiarygodnie wyspecjalizowany i masz określone wymagania, takie jak wydajność i… to wszystko, co mogę wymyślić. Podążanie tą drogą bez rozsądnej ilości zasobów jest trudnym - choć nie niemożliwym - zadaniem.

Masz kilka opcji; wybór zależy od modelu danych, rodzaju danych, które mają być obsługiwane, zamierzonego modelu użytkowania, kontroli dostępu, a także platformy dostarczania (WWW, HTML, Java Server, IIS, statyczny zestaw danych).

1. Rozszerz istniejący produkt, aby wykorzystać zestaw danych. Możesz spojrzeć na hosting instancji GeoServer na swoim (lub dedykowanym?) Komputerze i dostarczyć swoje dane w ten sposób. Jeśli Twoje dane nie są w formacie, który GeoServer może zrozumieć, masz możliwość napisania pakietu Java, aby zapewnić tę możliwość. Zaletą jest to, że masz dobrze zdefiniowany standard dostarczania informacji przestrzennych dla wizualizacji (WMS) i manipulacji / pobierania funkcji (WFS), a także innych korzyści, takich jak geocaching i kafelkowanie.
2. Wybierz opcję interfejsu API i masz pełną kontrolę nad interfejsem użytkownika. Które przychodzi do pierwszego zadania, Zdefiniuj, w jaki sposób użytkownicy mają wchodzić w interakcje z Twoimi danymi. Ten interfejs do danych będzie kluczem do sukcesu lub niepowodzenia. Jeśli twój interfejs jest zbyt otwarty, może stać się złożony i bezużyteczny, zbyt prosty i restrykcyjny, powolny lub bez adopcji. Tak czy inaczej, ważne będzie określenie sposobu, w jaki użytkownicy mają uzyskiwać dostęp do twoich danych, oraz sposób, w jaki spodziewasz się, że użytkownicy będą chcieli z nich korzystać.

Powodzenia, API nie jest małym przedsięwzięciem, ponieważ musisz wziąć pod uwagę metodę wydania i cykle, poprawki błędów, testy. Wszystko to przyczynia się do użyteczności. Nie mówię, nie rób tego, byłoby to wspaniałe doświadczenie. Jednak korzystanie z istniejącego produktu może być również pozytywnym doświadczeniem.