EV-oplader APIs

Wat wordt blootgelegd

Lezen en controleren zijn verschillende problemen

De leesstatus is een normaal API-probleem. Het geven van een commando is dat niet, omdat het commando naar fysieke apparatuur gaat die mogelijk niet luistert, en het antwoord dat je krijgt gaat over het verzoek en niet over de uitkomst.

• Een start op afstand die succes oplevert, betekent dat de opdracht is geaccepteerd, niet dat een auto aan het opladen is. De uitkomst komt later als een staatsverandering
• De oplader is mogelijk offline. In dat geval moet de opdracht in de wachtrij worden geplaatst, worden afgewezen of verlopen, en moet uw toepassing weten welke
• De fysieke wereld kan je tegenspreken: geen voertuig aangesloten, de ruimte bezet door een auto die niet oplaadt, de connector is niet vergrendeld
• Commando's moeten idempotent zijn, omdat een client die geen antwoord heeft gezien het opnieuw zal proberen

Controlebewerkingen worden dus afzonderlijk van leesbewerkingen geautoriseerd, en een integratie moet worden ontworpen om resultaten te observeren in plaats van te vertrouwen op bevestigingen.

Realtime updates ontvangen

1. 1

   Webhaken

   Het platform plaatst evenementen op u. Efficiënt en de juiste standaard. Vereist dat u bereikbaar bent, snel reageert en duplicaten en niet-bestelling leveringen afhandelt.

2. 2

   Streamen

   Een permanente verbinding voor continue telemetrie. Ideaal voor een live dashboard, onnodig voor de meeste applicaties, en het maakt je klant stateful.

3. 3

   Polling

   Eenvoudig, werkt altijd en schaalt slecht. Prima voor een handvol opladers en fout voor een netwerk. Het zorgt ook voor verouderde beschikbaarheid, wat de fout is die gebruikers opmerken.

De meeste integraties eindigen met webhooks voor evenementen en een beperkte peiling voor de specifieke dingen die nooit oud mogen zijn, wat in de praktijk beschikbaarheid is.

Authenticatie en scoping

• Referenties gelden voor een reeks opladers of locaties, niet voor het hele netwerk, dus een partnerintegratie kan niet verder reiken dan het eigen vermogen
• Lezen en beheren zijn gescheiden, zodat een analyse-integratie geen sessies kan starten
• Inloggegevens per integratie in plaats van gedeelde, zodat de toegang kan worden ingetrokken zonder al het andere te verbreken
• Gebruikerscontext waarin een eindgebruiker handelt, zodat een actie kan worden toegeschreven aan een persoon en niet aan een applicatie
• Een audittrail van commando's die ertoe doen na een incident

Tarieflimieten en goed gedrag op schaal

De foutmodus is meestal niet dat één cliënt misbruik maakt. Het zijn honderd goed opgevoede klanten die allemaal op dezelfde minuutgrens peilen, of een vloot van opladers die tegelijkertijd opnieuw verbinding maken na een regionale storing en elke integratie die in één keer reageert.

• Ga terug op afwijzing in plaats van het meteen opnieuw te proberen, waardoor een drukke periode in een uitval verandert
• Jitter geplande verzoeken in plaats van ze op de minuut af te stemmen
• Geef de voorkeur aan evenementen boven polling, waar de gegevens dit toelaten
• Cache wat niet verandert, wat de meeste metagegevens van de oplader zijn

Wat bewust niet wordt blootgelegd

Sommige dingen worden met opzet achtergehouden, en als je weet welke zaken dat zijn, kun je een integratieontwerp besparen dat niet kan werken.

• Alles waarmee een API-beller het veiligheidsgedrag kan beïnvloeden. De volgorde en bescherming van de contactor zijn door hun ontwerp niet adresseerbaar
• Ruwe persoonlijke gegevens die verder gaan dan wat de reikwijdte van de integratie rechtvaardigt
• Directe protocoltoegang tot de oplader, waardoor de eigen status en autorisatie van het platform zou worden omzeild
• De gegevens van andere tenants over een gedeelde implementatie zijn uiteraard de moeite waard om te bevestigen in plaats van aan te nemen