API: verschil tussen versies

Uit NORA Online
Naar navigatie springen Naar zoeken springen
Geen bewerkingssamenvatting
(omgezet naar code ipv element ivm foutmeldingen)
Regel 1: Regel 1:
{{#element:
{{Placeholder}}<noinclude>[[Categorie:Landingspagina's thema]]</noinclude><div class="themapagina">
|Elementtype=Thema
{{Agenda categorie|APIs}}{{Nieuwsblok categorie|APIs}}
|Beschrijving===Wat is een Application Programming Interface (API)?==
[[Image:Apisssss.gif|thumb|400px|right|alt=Wordcloud met woorden rond API, zoals developers, use en many.|Wordcloud API, overgenomen van [https://commons.wikimedia.org/wiki/File:Apisssss.gif wikimedia commons]]]
In Wikipedia wordt dat als volgt uitgelegd: https://nl.wikipedia.org/wiki/Application_programming_interface  
==Wat is een Application Programming Interface (API)?==
<br />
[https://nl.wikipedia.org/wiki/Application_programming_interface Wikipedia] beschrijft: ''Een API is een verzameling definities op basis waarvan een computerprogramma kan communiceren met een ander computerprogramma of onderdeel (meestal in de vorm van bibliotheken). Vaak vormen API's de scheiding tussen verschillende lagen van abstractie, zodat applicaties op een hoog niveau van abstractie kunnen werken en het minder abstracte werk uitbesteden aan andere programma's. Hierdoor hoeft bijvoorbeeld een tekenprogramma niet te weten hoe het de printer moet aansturen, maar roept het daarvoor een gespecialiseerd stuk software aan in een bibliotheek, via een afdruk-API.''
Een API is een verzameling definities op basis waarvan een computerprogramma kan communiceren met een ander computerprogramma of onderdeel (meestal in de vorm van bibliotheken). Vaak vormen API's de scheiding tussen verschillende lagen van abstractie, zodat applicaties op een hoog niveau van abstractie kunnen werken en het minder abstracte werk uitbesteden aan andere programma's.  
Hierdoor hoeft bijvoorbeeld een tekenprogramma niet te weten hoe het de printer moet aansturen, maar roept het daarvoor een gespecialiseerd stuk software aan in een bibliotheek, via een afdruk-API.  


En vanuit Computerworld wordt daarop aangevuld: https://computerworld.nl/development/74796-wat-is-een-api  
Een goede aanvulling hierop komt van [https://computerworld.nl/development/74796-wat-is-een-api Computerworld]:''Het aardige van een API is dat deze niet voor een gebruiker van een softwarepakket of bezoeker van een website zichtbaar is. De API werkt op de achtergrond en doet daar geruisloos zijn werk door met andere softwareprogrammatuur of het besturingssysteem te communiceren."
<br />
Het aardige van een API is dat deze niet voor een gebruiker van een softwarepakket of bezoeker van een website zichtbaar is. De API werkt op de achtergrond en doet daar geruisloos zijn werk door met andere softwareprogrammatuur of het besturingssysteem te communiceren.


Een API werkt dus als een interface tussen 2 of meer computerprogramma's (software), staat daardoor nooit op zichzelf, is dus een bijzondere bouwsteen en wordt beschouwd bij de Applicatielaag van het NORA [[vijflaagsmodel]].
Een API werkt dus als een interface tussen 2 of meer computerprogramma's (software), staat daardoor nooit op zichzelf, is dus een bijzondere bouwsteen en wordt beschouwd als deel van de [[Applicatielaag|applicatielaag]] van het NORA [[vijflaagsmodel]]. Bekijk ook eens dit filmpje van Mulesoft van 3,5 minuut op [https://www.youtube.com/watch?v=s7wmiS2mSXY youtube.com: What is an API?]
<br />
==Waarom zijn API's van belang?==
API’s gaan ons in staat stellen om de technische kant van het uitwisselen van gegevens stukken eenvoudiger te maken, met name ook over de grenzen van (overheids)organisaties heen. Dat kan als we API’s gaan ontwerpen met open standaarden (inrichtings-onafhankelijk), zodat ze te gebruiken zijn in verschillende processen of ketens. En als we die API’s publiekelijk gaan publiceren, zodat ze eenvoudig te hergebruiken zijn.<br />
Door het bundelen van onze ontwerp- en ontwikkelkennis kunnen we processen en ketens ontlasten doordat die API’s kunnen hergebruiken en ze niet zelf hoeven te ontwikkelen en bouwen.<br />
Een belangrijke voorwaarde voor deze technische gegevensuitwisseling is, dat vanuit het bestuur en management draagvlak moet bestaan voor verdergaande samenwerking tussen de betrokken (overheids)organisaties: de eigen "interne" processen zullen aangepast moeten worden aan overkoepelende keten-processen, waarbij de afhankelijkheden tussen die organisaties toenemen en de (formele) verantwoordelijkheidsverdeling opnieuw in balans moet worden gebracht. Overigens kunnen API's ook goed worden toegepast ''binnen'' een organisatie.<br />
Traditionele applicaties bestaan meestal uit grote brokken functionaliteit, die alleen beschikbaar zijn binnen de beveiligde grenzen van een organisatie. Deze applicaties zijn voorheen vooral gemaakt om een geheel proces te ondersteunen. Ze zijn vaak niet ontworpen met generieke software-componenten die door verschillende applicaties kunnen worden hergebruikt. Daardoor bevatten ze vaak functionaliteit die ook in andere applicaties voorkomen, zoals voor Identity & Access Management, Beveiliging en Privacy.<br />
Door nu achteraf generieke software-componenten te ontwikkelen -bijvoorbeeld in de vorm van API’s- kunnen we die traditionele applicaties verbouwen en mede samenstellen uit diverse kleinere software-componenten: daardoor ontstaat een meer flexibele applicatie.
</div>
<br clear="all" />


En als je liever uitleg krijgt via een leuk filmpje van 3½ min.: [https://www.youtube.com/watch?v=s7wmiS2mSXY What is an API?]
<div id="Functies" style="overflow:hidden;">
|Relevantie=API’s gaan ons in staat stellen om het uitwisselen van gegevens -technisch gezien- stukken eenvoudiger te maken, met name ook over de grenzen van (overheids)organisaties heen.
{| style="float:left; background-color:#E5F0F9; margin-right:8px; border:none; width:250px"
Dat kan indien we API’s gaan ontwerpen met open standaarden (inrichtingsonafhankelijk), zodat ze te gebruiken zijn in verschillende processen of ketens en indien we die API’s publiekelijk gaan publiceren, zodat ze eenvoudig te hergebruiken zijn.<br />
|-
Door het bundelen van onze ontwerp- en ontwikkelkennis kunnen we processen en ketens ontlasten doordat die API’s kunnen hergebruiken in plaats van dat ze die zelf moeten ontwikkelen en bouwen.<br />
!Direct aan de slag
<br />
|-
Een belangrijke voorwaarde voor deze technische gegevensuitwisseling is, dat vanuit het bestuur en management draagvlak moet bestaan voor verdergaande samenwerking tussen de betrokken (overheids)organisaties: de eigen "interne" processen zullen aangepast moeten worden aan overkoepelende keten-processen, waarbij de afhankelijkheden tussen die organisaties toenemen en de (formele) verantwoordelijkheidsverdeling opnieuw in balans moet worden gebracht.
| style="border:none; padding:5px 0 7px 0; margin-right:0px; vertical-align:top; height:400px" |
Wat doe je als Business-architect of Solution-architect om API’s te verwerken in het ontwerp van een (overheids)dienst?<br />


Overigens kunnen API's ook goed worden toegepast binnen een organisatie.<br />
: → Lees de [https://docs.geostandaarden.nl/api/API-Strategie/ NL API-strategie], die de kaders omvat voor het gebruik van API’s
Traditionele applicaties bestaan doorgaans uit grote brokken functionaliteit die alleen beschikbaar zijn binnen de beveiligde grenzen van een organisatie. Deze applicaties zijn voorheen vooral gemaakt om een geheel proces te ondersteunen. Ze zijn vaak niet ontworpen met generieke software-componenten die door verschillende applicaties kunnen worden hergebruikt. Daardoor bevatten ze vaak functionaliteit die ook in andere applicaties voorkomen, zoals voor Identity & Access Management, Beveiliging en Privacy.<br />
: → Maak de keuze voor API's zodra de processen waarmee de dienst wordt geleverd zijn uitgeschreven: Het WAT is bekend en het HOE kan ingevuld (handmatig of geautomatiseerd uitvoeren, welke organisatie, welke software e.d.)
Door nu achteraf generieke software-componenten te ontwikkelen -bijvoorbeeld in de vorm van API’s- kunnen we die traditionele applicaties verbouwen en mede samenstellen uit diverse kleinere software-componenten: daardoor ontstaat een meer flexibele applicatie.
: → Denk vanuit hergebruik van Landelijke Bouwstenen [[AP7]] en kijk welke API’s al beschikbaar zijn:
|Plaatje=Apisssss.gif
:: → [https://developer.overheid.nl/ developer.overheid.nl], nationale publicatieplek overheids API's
|Alt-tekst=Wordcloud met woorden rond API, zoals developers, use en many.
:: → [https://www.logius.nl/diensten/overheidsgegevensnl/overzichten# Logius en GDI], API’s vanuit de (GDI)
|Onderschrift=Wordcloud API, overgenomen van [https://commons.wikimedia.org/wiki/File:Apisssss.gif wikimedia commons]
:: → [http://www.programmableweb.com API library], internationale directory van ca. 22.000 bedrijfs-API’s
|Px=400
: → Vind de juiste (voorbeeld-) API voor jou op basis van Bedrijfsfuncties (Processen), Gegevens of Registraties <nog in onderzoek>
|Direct aan de slag=Wat doet een Business-architect dan wel Solution-architect om API’s te verwerken in het ontwerp van een (overheids)dienst?<br />
: → Maak API's onderdeel van je architectuur.
Denk dan aan zaken als:
:: → Voorbeelden van API-architecturen <nog op te nemen>
# Kennisnemen van de NL API-strategie, die de kaders omvat voor het gebruik van API’s: [https://docs.geostandaarden.nl/api/API-Strategie/ NL API-strategie]
|-
# De keuze voor het gebruik van een API in het ontwerp van een dienst, ontstaat op het moment dat de processen zijn uitgeschreven waarmee de dienst kan worden geleverd: dan is het WAT bekend en kan worden overgegaan op het HOE (handmatig of geautomatiseerd uitvoeren, welke organisatie, welke software e.d.)
|[[Image:puzzelstuk.png|250px]]
# Gedacht vanuit het hergebruik van Landelijke Bouwstenen (zie [https://www.noraonline.nl/wiki/Gebruik_de_landelijke_bouwstenen AP7]), kan je nagaan welke API’s beschikbaar zijn:
|}
# De Nationale site waar de Overheid API’s publiceert: [https://developer.overheid.nl/ DON]
{| style="float:left; background-color:#E5F0F9; margin-right:8px; border:none; width:250px"
# API’s werkend vanuit de Gemeenschappelijke Digitale Infrastructuur (GDI): [https://www.logius.nl/diensten/overheidsgegevensnl/overzichten# Logius en GDI]  
|-
# Een directory van ca. 22.000 API’s van Internationale bedrijven: [http://www.programmableweb.com API library]
!Samen leren & zoeken
# We onderzoeken nog vanuit welke kenmerken de API’s doorzoekbaar zullen worden, zoals Bedrijfsfuncties (Processen), Gegevens of Registraties
|-
# Voorbeelden van API-architecturen zijn: <nog op te nemen>
| style="border:none; padding:5px 0 7px 0; margin-right:0px; vertical-align:top; height:400px" |
|Samen leren en zoeken=Er zijn diverse (overheids)organisaties die zelf API’s ontwikkelen en publiceren voor gebruik door derden. We hebben een overzicht gemaakt van bij ons bekende overheidsorganisaties met contact-informatie. Bij hen kan je vragen hoe zij e.e.a. hebben aangepakt om hun dienstverlening te verbeteren door het werken met API’s.
Er zijn diverse (overheids)organisaties die zelf API’s ontwikkelen en publiceren voor gebruik door derden. We hebben een overzicht gemaakt van bij ons bekende overheidsorganisaties met contact-informatie. Bij hen kan je vragen hoe zij e.e.a. hebben aangepakt om hun dienstverlening te verbeteren door het werken met API’s.
|Links samen leren en zoeken=Zie <nog op te nemen overzicht>
Zie <nog op te nemen overzicht>
<br /><br />
<br /><br />
Het Forum Standaardisatie heeft bijeenkomsten gehouden over [https://www.forumstandaardisatie.nl/thema/application-programming-interfaces-api de API-economie].<br /><br />
Het Forum Standaardisatie heeft bijeenkomsten gehouden over [https://www.forumstandaardisatie.nl/thema/application-programming-interfaces-api de API-economie].<br /><br />
Kent u een overleg binnen de overheid dat zich bezig houdt met API’s? <br />
Kent u een overleg binnen de overheid dat zich bezig houdt met API’s? <br />
Neem dan contact op met [[NORA Beheer]].
Neem dan contact op met [[NORA Beheer]].
|Meer informatie=Nuttige linkjes:
|-
|Links meer informatie=:→ Binnen de Omgevingswet is een API-strategie opgesteld: [https://aandeslagmetdeomgevingswet.nl/digitaal-stelsel/technisch-aansluiten/standaarden/api-uri-strategie API-strategie & URI-strategie Digitaal Stelsel Omgevingswet]<br />
|[[Image:gereedschap.png|250px]]
|}
{| style="float:left; background-color:#E5F0F9; margin-right:8px; border:none; width:250px"
|-
!Meer informatie & Contact
|-
| style="border:none; padding:5px 0 7px 0; margin-right:0px; vertical-align:top; height:400px"  |
Nuttige linkjes:
:→ Binnen de Omgevingswet is een API-strategie opgesteld: [https://aandeslagmetdeomgevingswet.nl/digitaal-stelsel/technisch-aansluiten/standaarden/api-uri-strategie API-strategie & URI-strategie Digitaal Stelsel Omgevingswet]<br />


: → De meeste moderne API's zijn webgebaseerd (en doorgaans in JSON): daarom is het nuttig om ook over de URI's afspraken te maken. Zie daarom ook: [http://www.pilod.nl/wiki/Boek/URI-strategie 'Aanzet tot een nationale URI-Strategie voor Linked Data van de Nederlandse overheid' bij Pilod]<br />
: → De meeste moderne API's zijn webgebaseerd (en doorgaans in JSON): daarom is het nuttig om ook over de URI's afspraken te maken. Zie daarom ook: [http://www.pilod.nl/wiki/Boek/URI-strategie 'Aanzet tot een nationale URI-Strategie voor Linked Data van de Nederlandse overheid' bij Pilod]<br />


: → Ondanks "de Brexit" kunnen we toch goed leren van onze buren. Zie [https://www.gov.uk/government/news/hmrc-launches-ambitious-api-strategy API-strategie van Britse belastingdienst voor derden]
: → Ondanks "de Brexit" kunnen we toch goed leren van onze buren. Zie [https://www.gov.uk/government/news/hmrc-launches-ambitious-api-strategy API-strategie van Britse belastingdienst voor derden]
|Expertgroep=&nbsp;
 
|Expertgroep tekst=We zijn momenteel een expertgroep voor API-architectuur aan het vormen.
Dit thema wordt beheerd door experts uit overheid en marktpartijen (momenteel in oprichting):
|Contactpersoon=Bert Lukien
: → [[Expertgroep API's]]
|Contactgegevens={{Maillink|to=bert.lukkien@ictu.nl|cc=nora@ictu.nl|subject=contact met betrekking tot API's|text=bert.lukkien@ictu.nl}}
Contactpersoon is Bert Lukien (ICTU),
}}
: → {{Maillink|to=bert.lukkien@ictu.nl|cc=nora@ictu.nl|subject=contact met betrekking tot API's|text=bert.lukkien@ictu.nl}}
{{Placeholder}}
 
[[Categorie:APIs]]
|-
|[[Image:contact.png|250px]]
|}
<div style="float:left; margin-right:2px; max-width:380px" class="hoofdpagina">
 
</div>
</div>
<references />
<noinclude>[[Categorie:APIs]]
{{Domein toevoegen|Domein Generiek}}
[[Laag binnen vijflaagsmodel::4|  ]]</noinclude>

Versie van 28 okt 2019 14:22


Deze pagina is in opbouw. Kom later terug om het resultaat te zien of neem contact op met nora@ictu.nl als je mee wilt werken aan de eerste concepten.

Wordcloud met woorden rond API, zoals developers, use en many.
Wordcloud API, overgenomen van wikimedia commons

Wat is een Application Programming Interface (API)?[bewerken]

Wikipedia beschrijft: Een API is een verzameling definities op basis waarvan een computerprogramma kan communiceren met een ander computerprogramma of onderdeel (meestal in de vorm van bibliotheken). Vaak vormen API's de scheiding tussen verschillende lagen van abstractie, zodat applicaties op een hoog niveau van abstractie kunnen werken en het minder abstracte werk uitbesteden aan andere programma's. Hierdoor hoeft bijvoorbeeld een tekenprogramma niet te weten hoe het de printer moet aansturen, maar roept het daarvoor een gespecialiseerd stuk software aan in een bibliotheek, via een afdruk-API.

Een goede aanvulling hierop komt van Computerworld:Het aardige van een API is dat deze niet voor een gebruiker van een softwarepakket of bezoeker van een website zichtbaar is. De API werkt op de achtergrond en doet daar geruisloos zijn werk door met andere softwareprogrammatuur of het besturingssysteem te communiceren."

Een API werkt dus als een interface tussen 2 of meer computerprogramma's (software), staat daardoor nooit op zichzelf, is dus een bijzondere bouwsteen en wordt beschouwd als deel van de applicatielaag van het NORA vijflaagsmodel. Bekijk ook eens dit filmpje van Mulesoft van 3,5 minuut op youtube.com: What is an API?

Waarom zijn API's van belang?[bewerken]

API’s gaan ons in staat stellen om de technische kant van het uitwisselen van gegevens stukken eenvoudiger te maken, met name ook over de grenzen van (overheids)organisaties heen. Dat kan als we API’s gaan ontwerpen met open standaarden (inrichtings-onafhankelijk), zodat ze te gebruiken zijn in verschillende processen of ketens. En als we die API’s publiekelijk gaan publiceren, zodat ze eenvoudig te hergebruiken zijn.
Door het bundelen van onze ontwerp- en ontwikkelkennis kunnen we processen en ketens ontlasten doordat die API’s kunnen hergebruiken en ze niet zelf hoeven te ontwikkelen en bouwen.
Een belangrijke voorwaarde voor deze technische gegevensuitwisseling is, dat vanuit het bestuur en management draagvlak moet bestaan voor verdergaande samenwerking tussen de betrokken (overheids)organisaties: de eigen "interne" processen zullen aangepast moeten worden aan overkoepelende keten-processen, waarbij de afhankelijkheden tussen die organisaties toenemen en de (formele) verantwoordelijkheidsverdeling opnieuw in balans moet worden gebracht. Overigens kunnen API's ook goed worden toegepast binnen een organisatie.
Traditionele applicaties bestaan meestal uit grote brokken functionaliteit, die alleen beschikbaar zijn binnen de beveiligde grenzen van een organisatie. Deze applicaties zijn voorheen vooral gemaakt om een geheel proces te ondersteunen. Ze zijn vaak niet ontworpen met generieke software-componenten die door verschillende applicaties kunnen worden hergebruikt. Daardoor bevatten ze vaak functionaliteit die ook in andere applicaties voorkomen, zoals voor Identity & Access Management, Beveiliging en Privacy.
Door nu achteraf generieke software-componenten te ontwikkelen -bijvoorbeeld in de vorm van API’s- kunnen we die traditionele applicaties verbouwen en mede samenstellen uit diverse kleinere software-componenten: daardoor ontstaat een meer flexibele applicatie.


Direct aan de slag

Wat doe je als Business-architect of Solution-architect om API’s te verwerken in het ontwerp van een (overheids)dienst?

→ Lees de NL API-strategie, die de kaders omvat voor het gebruik van API’s
→ Maak de keuze voor API's zodra de processen waarmee de dienst wordt geleverd zijn uitgeschreven: Het WAT is bekend en het HOE kan ingevuld (handmatig of geautomatiseerd uitvoeren, welke organisatie, welke software e.d.)
→ Denk vanuit hergebruik van Landelijke Bouwstenen Gebruik de landelijke bouwstenen en kijk welke API’s al beschikbaar zijn:
→ developer.overheid.nl, nationale publicatieplek overheids API's
→ Logius en GDI, API’s vanuit de (GDI)
→ API library, internationale directory van ca. 22.000 bedrijfs-API’s
→ Vind de juiste (voorbeeld-) API voor jou op basis van Bedrijfsfuncties (Processen), Gegevens of Registraties <nog in onderzoek>
→ Maak API's onderdeel van je architectuur.
→ Voorbeelden van API-architecturen <nog op te nemen>
Puzzelstuk.png
Samen leren & zoeken

Er zijn diverse (overheids)organisaties die zelf API’s ontwikkelen en publiceren voor gebruik door derden. We hebben een overzicht gemaakt van bij ons bekende overheidsorganisaties met contact-informatie. Bij hen kan je vragen hoe zij e.e.a. hebben aangepakt om hun dienstverlening te verbeteren door het werken met API’s. Zie <nog op te nemen overzicht>

Het Forum Standaardisatie heeft bijeenkomsten gehouden over de API-economie.

Kent u een overleg binnen de overheid dat zich bezig houdt met API’s?
Neem dan contact op met NORA Beheer.

Gereedschap.png
Meer informatie & Contact

Nuttige linkjes:

→ Binnen de Omgevingswet is een API-strategie opgesteld: API-strategie & URI-strategie Digitaal Stelsel Omgevingswet
→ De meeste moderne API's zijn webgebaseerd (en doorgaans in JSON): daarom is het nuttig om ook over de URI's afspraken te maken. Zie daarom ook: 'Aanzet tot een nationale URI-Strategie voor Linked Data van de Nederlandse overheid' bij Pilod
→ Ondanks "de Brexit" kunnen we toch goed leren van onze buren. Zie API-strategie van Britse belastingdienst voor derden

Dit thema wordt beheerd door experts uit overheid en marktpartijen (momenteel in oprichting):

→ Expertgroep API's

Contactpersoon is Bert Lukien (ICTU),

→ bert.lukkien@ictu.nl
Contact.png


Iedere persoon, organisatie of functionele eenheid die gebruik maakt van een informatiesysteem

Nederlandse Overheid Referentie Architectuur.

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=API&oldid=38701"