Införa mer flexibilitet för API-registrering

[larwa99]

I dagsläget registreras bara en specifik bas-URL i "SupplierEntry" i den centrala katalogtjänsten vilket ställer krav på en förutbestämd namngivningsstruktur för API:ets alla endpoints och det kan orsaka svårigheter att samexistera med ett nätbolags andra API:er beroende på struktur och namngivningsstandard. Det är även så att vissa delar av API:et lämpar sig för att vara helt öppna medan andra kräver authentisering. Även här kan det finnas bolagsspecifik namngivning som krockar med en förutbestämd namngivningsstruktur.

För att tillåta mer flexibilitet skulle en variant vara att varje endpoint registreras separat i "SupplierEntry". Ett svar skulle till exempel kunna se ut i stil med:

    {
      "id": "2dbff828-d737-42fc-8d4c-1217bb8fe41f",
      "meteringPointIdFrom": "735999144000000000",
      "meteringPointIdTo": "735999144999999999",
      "companyName": "Tekniska verken Linköping Nät AB",
      "companyOrgNo": "556483-4926",
      "apiTariffs": "https://api.tekniskaverken.net/subscription/public/",
      "apiSearch": "https://api.tekniskaverken.net/subscription/member/",
      "apiPrices": "https://api.tekniskaverken.net/subscription/public/",
      "userDocUrlOrEmail": ""
    }

En annan variant är att skilja enbart på öppna API:er och de som kräver authentisering om det går att definiera på ett universellt sätt.

[avajadi]

Om vi anger flera olika endpoints med fri namngivning, behövs det inte flera swaggerfiler då?

[larwa99]

Om vi anger flera olika endpoints med fri namngivning, behövs det inte flera swaggerfiler då?

Jo, vi behöver dela upp dem i lika många filer som vi vill kunna registrera separat.

[avajadi]

Förtar inte det syftet med en OpenAPI-specifikation lite? Den som skall bygga klienter får generera separata klientklasser eller motsvarande för varje del då?
Dessutom, vad händer om en elnätsoperatör väljer att implementera vissa delar, men inte andra, hur skall den som konsumerar hantera det?
Vad är fördelen, från ert perspektiv?

[larwa99]

Förtar inte det syftet med en OpenAPI-specifikation lite? Den som skall bygga klienter får generera separata klientklasser eller motsvarande för varje del då?
Dessutom, vad händer om en elnätsoperatör väljer att implementera vissa delar, men inte andra, hur skall den som konsumerar hantera det?
Vad är fördelen, från ert perspektiv?

Problemet är att man kanske förutsätter lite för mycket angående när det gäller hur en elnätsoperatör väljer att implementera API:et. Vi kan redan nu konstatera att både Tekniska verken och Göteborg Energi väljer att exkludera den delen av API:et som exponerar information kopplat till en viss mpid. I Tekniska verkens fall publiceras tariff-definitionerna som öppen information utan krav på autentisering i en särskild del av vår API-struktur: https://api.tekniskaverken.net/subscription/public/tariffs

Om och när vi inför de nu exkluderade endpoints som hanterar mpid-information så uppstår problem om vi tvingas samlokalisera de olika typerna av endpoints eftersom "public" bara ska innehålla helt öppna API:er utan krav på autentisering. Jag tror därför att vi tjänar på att åtminstone hålla isär tariff-relaterade API:er (definitioner + prisinformation) med de som är mpid-relaterade (potentiell känslig information).