Een Data Driven Organization opbouwen, Deel #6: Consumeer een REST API zonder te coderen

bharold

"Je moet een connector schrijven".  Dat zeiden mensen vroeger als er een integratie moest worden gebouwd tussen ArcGIS en een ander systeem.  Tegenwoordig is het informatietechnologielandschap echter volwassen geworden en draait de communicatie tussen apps om een handvol patronen die iedereen (die relevant wil blijven) gebruikt.  ArcGIS Data Interoperability beweegt zich binnen dit domein en spreekt dezelfde taal.<\/P>

Een duidelijke winnaar heet REST<\/A>, en omdat ik geen computerwetenschapper ben, zal ik niet ingaan op wat je zelf kunt lezen, het enige dat mij interesseert is dat vrijwel alles op het web data kan verzenden en ontvangen op een manier die ik gemakkelijk kan gebruiken (voornamelijk JSON, met enkele uitzonderingen die nog XML gebruiken en enkelen die de bruikbaarheid oprekken met protocol buffer payloads, maar ik houd ze voor je in de gaten, ik denk dat dat voorbij zal gaan 😉<\/span>.) met ArcGIS Data Interoperability.<\/P>Ik moet een afbeelding toevoegen voordat de zoekmachines me zat worden en ik niet geïndexeerd word.  Hier is een  workspace (StubOutAPIJSONReading.fmw<\/STRONG> in de post download) die ik gebruikte om aanvankelijk een API te verkennen (details volgen):<\/P>Exploring an API<\/span><\/span><\/P>Mijn voorbeeld-API wordt gepubliceerd door de goede mensen van Clarity Movement.<\/A><\/P>

Clarity is opgericht in 2014 om de wereldwijde luchtvervuilingscrisis aan te pakken en biedt nu kosteneffectieve, schaalbare en betrouwbare luchtkwaliteitsmonitoring aan klanten in meer dan 60 landen wereldwijd. De oplossing van Clarity stelt overheden en gemeenschappen in staat om luchtkwaliteitsgegevens met hogere resolutie te verzamelen door bestaande regelgevende monitors aan te vullen met dichte netwerken van continu gekalibreerde luchtkwaliteitsensoren.<\/P>

Ik vind Clarity's

Measurements<\/A>-endpoint een goed voorbeeld van het meest voorkomende patroon dat je zult tegenkomen, namelijk het verwerken van JSON<\/STRONG>-gegevens die worden teruggegeven door een HTTP<\/STRONG>-oproep.  Voordat je in paniek raakt over zaken als transportprotocollen en JSON-parsing, ontspan!  Data Interoperability regelt het allemaal voor je, wat maar goed is ook want anders zou je zulke dingen moeten lezen:<\/P> <\/P> <\/P> <\/P> <\/P>{
"_id": "6137a995cd42fd51fcda7083",
"device": "609935dcc9348052e0c5d917",
"deviceCode": "AY989QV6",
"time": "2021-09-07T17:00:00.000Z",
"location": {
"coordinates": [
-120.90439519586954,
36.01958888490562
],
"type": "Point"
},
"recId": "averaged:AY989QV6:hour:2021-09-07T18:00:00",
"characteristics": {
"relHumid": {
"value": 30.428397178649904,
"weight": 4,
"raw": 30.428397178649904
},
"temperature": {
"value": 30.882064819335939,
"weight": 4,
"raw": 30.882064819335939
},
"pm2_5ConcNum": {
"value": 24.072547912597658,
"weight": 4,
"raw": 24.072547912597658
},
"pm2_5ConcMass": {
"value": 13.646130166709775,
"weight": 4,
"raw": 21.126213550567628,
"calibratedValue": 13.646130166709775,
"epaNowCast": 15.097605519225573
},
"pm1ConcNum": {
"value": 22.670581817626954,
"weight": 4,
"raw": 22.670581817626954
},
"pm1ConcMass": {
"value": 12.186892986297608,
"weight": 4,
"raw": 12.186892986297608
},
"pm10ConcNum": {
      value": 24.33531427383423,
        weight": 4,
        raw": 24.33531427383423
    },
    pm10ConcMass": {
        value": 28.42475652694702,
        weight": 4,
        raw": 28.42475652694702
    },
    no2Conc": {
        value": -6.413380280137062,
        weight": 4,
        raw": -6.413380280137062
    },
    pm2_5ConcMass_24HourRollingMean": {
        value": 15.003665288163619,
        weight": 88,
        raw": 27.317325342785229,
        calibratedValue": 15.003665288163619
    },
    pm2_5ConcNum_24HourRollingMean": {
        value": 26.923120065168903,
        weight": 88,
        raw": 26.923120065168903
    },
    pm10ConcMass_24HourRollingMean": {
        value": 37.67677915096283,
        weight": 88,
        raw": 37.67677915096283
    },
    pm10ConcNum_24HourRollingMean": {
        value": 27.273549459197306,
        weight": 88,
        raw": 27.273549459197306
    }
},
average":"hour"
}<\/code><\/pre> <\/P> <\/P> <\/P> <\/P>De taak is om deze gegevens om te zetten in een hosted feature service en het onderhoud van de service te automatiseren.<\/STRONG><\/P>Een voordeel van een GIS-achtergrond is dat je waarschijnlijk wat Python kent, en JSON-payloads zoals hierboven lijken precies op Python-dictionaries en lijsten.  Je hoeft maar een paar trucjes te leren voordat je vrijwel elke REST API aankunt.<\/P>Truc #1:  Gebruik maken van HTTPCaller.<\/STRONG><\/P>HTTPCaller<\/span><\/span><\/P> <\/P> HTTPCaller<\/A> laat je eenvoudig een formulier invullen om een weboproep te doen en een antwoord te ontvangen (in dit geval JSON).  Eerst moet je je API-documentatie<\/A> lezen en de vereiste parameters bepalen, plus eventuele optionele die je wilt, en of je een GET<\/STRONG>- of POST<\/STRONG>-methode gebruikt.  GET is meestal voor kortere URL's, POST ondersteunt langere URL's en ook uploads die in een Body worden meegegeven.  Een ander aspect is authenticatie.  Veel API's vereisen een API-sleutel (zoals hier te zien) of een token.  Meestal verlopen sleutels niet, tokens wel, plus tokens vereisen een generatie-stap (die apart kan worden gedaan via HTTP of via OAuth2 in een web connection<\/A><\/STRONG> die je instelt voor je account).  Mijn voorbeeld vereist een sleutel.  Mijn oproep vraagt om een JSON-array van 10 luchtkwaliteitsmetingen en retourneert deze in een attribuut genaamd _response_body<\/STRONG>.<\/P>Truc #2:  JSON uitpakken<\/STRONG><\/P>Ik ga willekeurige aantallen luchtkwaliteitsmetingen verwerken maar eerst moet ik uitzoeken hoe ik data uit de JSON haal.  Ik vroeg om 10 luchtkwaliteitsmetingen dus de teruggegeven JSON zal een array zijn.  Elke meting in de array heeft hetzelfde schema als gebruikt door de velden van mijn features - de bovenstaande JSON is een feature van een meting.  Ik moet uitzoeken hoe ik veldwaarden kan extraheren.  De eenvoudigste manier is om de JSON van één array-feature naar een bestand te schrijven en gebruik te maken van de data-bewuste mogelijkheid van JSONExtractor<\/A> zodat ik queries kan bouwen zonder enige JSON-querycode te schrijven.<\/P>

Als ik tijdelijk<\/<\strong> de JSONExtractor instel om uit een JSON-bestand te lezen, krijg ik een handige picker om mijn JSON-queries te bouwen.  Daarna kan ik de JSONExtractor kopiëren naar een productietool, instellen om te lezen uit het inkomende feature-JSON-attribuut waarmee hij alle beschikbare veldwaarden zal extraheren en blootleggen.  Hoe makkelijk is dat!<\p>

Hier is mijn JSONExtractor terwijl ik lees uit een bestand en mijn queries bouw:<\p>

JSONExtractor<\span>

P>

Nu gaat alles bergafwaarts naar het creëren en onderhouden van mijn feature service.<\p>

Clarity2GDB.fmw gebruikt de hierboven uitgevoerde JSON-verkenning om een feature class weg te schrijven in de home geodatabase van mijn Pro-project - er wordt wat hernoeming van attributen gedaan, en natuurlijk krijgen ze hun gewenste types toegewezen bij het schrijven.<\p>

Clarity2GDB<\span>

Daarna kan ik na het creëren van mijn feature service vanuit de geodatabase feature class het werk hergebruiken om de feature service te onderhouden met RefreshClarityService.fmw, dat alleen verschilt bij de writer stap. Je zult merken dat alleen gewijzigde features naar de doeldienst worden geschreven, de workspace heeft een parameter die het geschiedenisinterval voor mijn features instelt, features in de service ouder dan dat worden verwijderd.<\/P>

RefreshClarityService<\/span><\/span><\/P> Deze laatste tool kan gepland worden of op aanvraag worden uitgevoerd.<\/P>Dat is het!  Ik heb de complexiteit van webintegratie overwonnen en heb een feature service die ik kan gebruiken om mijn kaarten, apps en dashboards aan te drijven.<\/P>Feature Service<\/span><\/span><\/P>De blogdownload bevat de ETL-tools die ik heb gebruikt, minus een functionele API-sleutel, neem contact op met Clarity als je een integratie wilt testen en implementeren.<\/P> <\/P>