Aanbevelingen voor API's in het ontwerp van een dienst: verschil tussen versies

Uit NORA Online
Naar navigatie springen Naar zoeken springen
(sjabloon toegevoegd en 1e vulling)
 
k (interpunctie)
Regel 1: Regel 1:
{{APIs}}
{{APIs}}


Handvatten voor een Business c.q. Solution Architect, die de architectuur van een dienst gaat beschrijven:
Hoe kan je API’s gebruiken bij het (her)ontwerp van een specifieke dienst?
 
Hieronder geven we handvatten voor een Business c.q. Solution Architect, die de architectuur van een dienst gaat beschrijven:
# Ga bij de Enterprise Architect van jouw organisatie na of de organisatie afdoende is ingericht op het gebruik van API’s. Zie ook [[Aanbevelingen voor API's in de Enterprise Architectuur]] Als dat namelijk niet zo is, dan zal dat eerst geregeld moeten worden of kan het gebruik van API’s wellicht beter nog niet in het ontwerp van de dienst worden opgenomen.
# Ga bij de Enterprise Architect van jouw organisatie na of de organisatie afdoende is ingericht op het gebruik van API’s. Zie ook [[Aanbevelingen voor API's in de Enterprise Architectuur]] Als dat namelijk niet zo is, dan zal dat eerst geregeld moeten worden of kan het gebruik van API’s wellicht beter nog niet in het ontwerp van de dienst worden opgenomen.
# Zorg er voor dat een goede beschrijving van de dienst beschikbaar is (zie AP5), in de zin dat duidelijk is:
# Zorg er voor dat een goede beschrijving van de dienst beschikbaar is (zie AP5), in de zin dat duidelijk is:

Versie van 26 feb 2020 16:23


API
Onderdeel van
Thema's
Contact
Peter Haasnoot
peter.haasnoot@logius.nl
Status
Actueel


Hoe kan je API’s gebruiken bij het (her)ontwerp van een specifieke dienst?

Hieronder geven we handvatten voor een Business c.q. Solution Architect, die de architectuur van een dienst gaat beschrijven:

  1. Ga bij de Enterprise Architect van jouw organisatie na of de organisatie afdoende is ingericht op het gebruik van API’s. Zie ook Aanbevelingen voor API's in de Enterprise Architectuur Als dat namelijk niet zo is, dan zal dat eerst geregeld moeten worden of kan het gebruik van API’s wellicht beter nog niet in het ontwerp van de dienst worden opgenomen.
  2. Zorg er voor dat een goede beschrijving van de dienst beschikbaar is (zie AP5), in de zin dat duidelijk is:
    1. wat het resultaat voor de burger is;
    2. met welke processen die dienst wordt geleverd;
    3. welke (business)functies daartoe nodig zijn;
  3. Zorg voor duidelijkheid over welke gegevens daartoe nodig zijn: de informatie-objecten en hun onderlinge relaties (zie AP17);
  4. Zorg voor duidelijkheid over de bron-registratie waaruit elk van deze gegevens zal worden afgenomen (zie AP13);
  5. Ga na hoe de (business)functies het beste kunnen worden ingevuld (handmatig of geautomatiseerd). Denk daarbij eerst vanuit hergebruik: Standaard oplossingen (AP6) of Landelijke bouwstenen (AP7), waaronder ook API’s; NB. De aangegeven AP’s omvatten handvatten voor het hergebruik en verwijzen onder meer naar vindplaatsen van API’s, zoals DON
  6. Als hergebruik niet mogelijk is, kijk dan naar de optie voor “maatwerk” om 1 of meer API’s te ontwerpen waarmee de dienst kan worden gerealiseerd en volg de ontwerp richtlijnen: https://docs.geostandaarden.nl/api/API-Designrules/

Een beschrijving van een complex geheel, en van de principes die van toepassing zijn op de ontwikkeling van het geheel en zijn onderdelen.

Overgenomen van "https://www.noraonline.nl/index.php?title=Aanbevelingen_voor_API%27s_in_het_ontwerp_van_een_dienst&oldid=40591"