API: verschil tussen versies
k (codefix, spelling, en opmaakconventie) |
(→Waarom zijn API's van belang?: enters ipv breaks, geeft betere bladspiegel) |
||
| (4 tussenliggende versies door 4 gebruikers niet weergegeven) | |||
| Regel 1: | Regel 1: | ||
{{Placeholder}} | {{Placeholder}}{{Sjabloon:APIs|auteurs=[[API-community]]|feedback=|onderdeel van=Thema's}} | ||
{{Agenda categorie|APIs}}{{Nieuwsblok categorie|APIs}} | {{Agenda categorie| APIs}}{{Nieuwsblok categorie|APIs}} | ||
[[ | <noinclude>[[Categorie:Landingspagina's thema]]</noinclude> | ||
==Wat is een Application Programming Interface (API)?== | ==Wat is een Application Programming Interface (API)?== | ||
[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.'' | [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 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. | 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.'' | ||
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]]. <br /> | 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]]. <br /> | ||
| Regel 12: | Regel 12: | ||
==Waarom zijn API's van belang?== | ==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. | 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. | 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. | ||
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. | |||
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. | 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> | </div> | ||
<div id="Functies" style="overflow:hidden;"> | <div id="Functies" style="overflow:hidden;"> | ||
{| style="float:left; background-color:#E5F0F9; margin-right:8px; border:none; width:250px" | {| style="float:left; background-color:#E5F0F9; margin-right:8px; border:none; width:250px" | ||
Versie van 3 feb 2023 13:30
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 is op Nationaal niveau geregeld om het gebruik van API's door (overheids)organisaties optimaal te benutten?
Wat moet daarnaast nog meer worden geregeld? Welke behoefte bestaat bij de voorlopers? En bij de volgers? Wat kunnen we her-gebruiken van Internationale afspraken en voorzieningen? Wat doe je als Enterprise Architect om de architectuur van jouw organisatie aan te passen opdat ook met API’s kan worden gewerkt? Wat doe je als Business- of Solution-architect om API’s te verwerken in het ontwerp van een (overheids)dienst? |
|
| 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. |
|
| Meer informatie & Contact |
|---|
|
Nuttige linkjes:
Dit thema wordt beheerd door experts van de overheid en marktpartijen: Contactpersoon is Peter Haasnoot, |
|