Gegevensuitwisseling tussen meerdere platforms is in het tijdperk van integraties crucialer dan ooit. Denk aan een webwinkel zonder integraties. Uw website zou systemen moeten ontwikkelen voor het beheer van gebruikersaccounts, e-mailabonnementen, betalingsverwerking, verzending en andere taken naast het beheer van productlijsten. Het zou effectiever zijn om deze taken uit te besteden aan andere aanbieders, aangezien dit geen schaalbare optie is.
Application Programming Interfaces, of web API's, gebruiken softwareprogramma's om met elkaar te communiceren. API's bieden een consistent protocol voor het uitwisselen van gegevens tussen twee programma's. Met behulp van web-API's kan uw webwinkel communiceren met leveringssoftware, klantapplicaties, betaalapplicaties en alle andere vereiste verbindingen.
Er zijn verschillende manieren om een API te maken; als u echter softwareverbindingen aan uw diensten wilt toevoegen, is er één unieke techniek waarmee u bekend moet zijn: REST API's webservices. In dit artikel bespreken we REST API voorbeelden, wat REST API is, hoe REST APIs werken, waar REST APIs voor gebruikt worden, de geschiedenis, de elementen en meer.
Wat is precies een REST API?
Representational state transfer of REST API's webservices zijn de meest standaard praktijk voor het koppelen van componenten in microservices frameworks, omdat ze een veelzijdige, draagbare manier bieden om apps te integreren. REST is een populair API-ontwerp dat we gebruiken om op een gestandaardiseerde en voorspelbare manier te communiceren met interne en externe belanghebbenden.
Gebruikers van webapplicaties maken vaak gebruik van REST API's webdiensten om met elkaar te communiceren. Bijvoorbeeld het verkrijgen en bekijken van accountgegevens in een programma voor sociale media. De REST API's browsers kunnen worden gezien als de syntax van het web. Online klanten maken gebruik van web API's om toegang tot digitale activiteiten te bieden en te beheren naarmate het gebruik van de cloud toeneemt.
Het ontwerpen van web API's die klanten in staat stellen om dynamisch in een verspreide context verbinding te maken met digitale webdiensten, deze te beheren en zich ermee bezig te houden, is een verstandige beslissing. Websites als Google, eBay, Facebook, Amazon en Twitter maken gebruik van REST-webdiensten. Cliëntapplicaties kunnen nu REST gebruiken om toegang te krijgen tot deze webdiensten.
REST-technologie geniet de voorkeur boven andere verwante technologieën. Dit komt omdat REST webdiensten minder bandbreedte verbruiken, waardoor ze ideaal zijn voor efficient online activiteiten. REST-webdiensten kunnen ook worden ontwikkeld met programmeertalen als JavaScript of Python.
Hoe werken REST API's?
Om te weten hoe REST API's werken, moeten we enkele belangrijke termen definiëren:
Client
Een API gebruiker wordt een client genoemd. De client stuurt queries naar de web API's om gegevens te verkrijgen of wijzigingen in het programma aan te brengen. Uw internetbrowser is een client; hij communiceert met verschillende web-API's om pagina-inhoud te verkrijgen. Uw computer ontvangt de gewenste informatie, die vervolgens op het scherm wordt getoond.
Dit zijn de populairste HTTP-methoden:
- Gebruik het GET-verzoek om gevraagde gegevens of gevraagde bronnen terug te sturen.
- Gebruik de POST-aanvraag om een nieuwe bron aan te maken
- Gebruik de PUT-aanvraag om wijzigingen aan te brengen in een bestaande bron of deze te blijven bijwerken
- Gebruik de DELETE opdracht om van een bron af te komen.
Een HTTP-verzoek aan de API van Youtube kan bijvoorbeeld een GET-verzoek resource zijn voor een bepaalde video of post, of een POST-verzoek om een nieuwe foto te publiceren. U kunt de POST-verzoekmethode gebruiken om nieuwe berichten te publiceren. Evenzo kan een customer web services platform dat integreert met een auto-attendant implementatie de PUT instructie gebruiken om een aangepaste hallo bij te werken of te verwijderen.
Get verzoek
- GET request caching is mogelijk. De geschiedenis van de browser bevat GET requests.
- Bookmarking van GET-verzoeken is mogelijk.
- Gebruik nooit GET-verzoeken terwijl u met kritisch materiaal werkt.
- Er zijn lengtebeperkingen voor GET-verzoeken.
- Via GET-verzoeken worden alleen gegevens opgevraagd.
De POST-methode
Het POST-verzoek is een postmethode voor het verzenden van informatie naar een server om bronnen toe te voegen of bij te werken. Het verzoeklichaam van een HTTP-verzoek bevat de gegevens die aan de serverzijde worden gepubliceerd:
- POST-verzoeken postmethode gaan nooit in een cache.
- POST-verzoeken worden niet opgeslagen in de geschiedenis van de browser.
- POST-verzoeken zijn niet bookmarkable
Antwoord lichaam
Response body is een van de belangrijke elementen van RESTful API. De gevraagde gegevens worden opgenomen in de respons body. De respons body kan gegevens bevatten met betrekking tot de output en output logica poorten.
Bron
Alle gegevens die de web-API's aan de gebruiker kunnen geven, zijn een resource. Een persoon, pagina, foto of opmerking kunnen bijvoorbeeld allemaal worden beschouwd als bronnen in de Facebook API. De resource identifier is een speciale term die aan elke resource wordt gegeven.
Webserver
Het programma dat de request body van de klant accepteert, gebruikt een webserver, die de resources herbergt waar de consument om vraagt. De server kan met klanten communiceren via een API zonder klanten onmiddellijk toegang te bieden tot de informatie in zijn databases. Wanneer een gebruiker RESTful web services benadert om een request body in te dienen, stuurt de server een genormaliseerde weergave van de toestand van de resource naar de browser.
Dit betekent dat de server op de een of andere manier niet de exacte bron aan de client voorlegt, maar eerder de toestand ervan weergeeft, d.w.z. de toestand van de bron op een specifieke tijdstempel. Om de begrijpelijkheid te bevorderen, worden antwoorden teruggestuurd in een lichtgewicht formaat.
JSON (JavaScript Object Notation) wordt veel gebruikt omdat het leesbaar is voor zowel mensen als machines en uitblinkt in het bevorderen van webtoegankelijkheid. JSON wordt voornamelijk gebruikt voor het verzenden van request body in webapplicaties en client-toepassingen. Het is een compatibele vorm met verschillende coderingen. Andere API-gegevensformaten dan JSON zijn XML, YAML, CSV, HTML en gewone tekst. Gebruikers van API's kunnen elk gewenst gegevensformaat kiezen door gebruik te maken van aangepaste mediatypen.
Geschiedenis van REST API's
Veel programmeurs moesten vóór REST werken met SOAP om API's in te bouwen. Het bouwen, gebruiken en debuggen van SOAP waren notoir moeilijke taken. Gelukkig werd REST ontwikkeld door een team van programmeurs onder leiding van Roy Fielding, waardoor de API-omgeving voorgoed veranderde.
Hier volgt een chronologie van de ontwikkeling van REST API's in de loop der tijd:
Vóór REST
Programmeurs schreven handmatig een XML-bestand met daarin een Remote Procedure Call (RPC) om web-API's te verbinden met behulp van SOAP. Daarna POSTten ontwerpers hun SOAP-pakket naar het gespecificeerde eindpunt.
In het jaar 2000
Een team van programmeurs onder leiding van Roy Fielding koos ervoor om een raamwerk te ontwikkelen waarmee elke server met elke andere server kon communiceren. Hij legde de beperkingen voor REST API's vast. Doordat deze richtlijnen universeel zijn, wordt het ontwikkelen van software eenvoudiger.
In het jaar 2002
eBay ontwikkelde in 2002 zijn RESTful API en stelde zijn marktplaats open voor elke website die ervan zou kunnen profiteren. Hierdoor raakte een andere titaan van de e-commerce, Amazon, geïnteresseerd en bracht in 2002 zijn RESTful API uit.
In het jaar 2004-2006
In 2004 werden de RESTful web services van Flickr vrijgegeven, waardoor schrijvers snel foto's konden toevoegen aan hun websites en social media posts. Toen Twitter en Facebook merkten dat een aanzienlijk aantal programmeurs de websites doorzochten en "Frankenstein" API's maakten, gaven ze allebei ongeveer twee jaar later hun API's vrij.
In het jaar 2006-heden
RESTful web services zijn nu algemeen geaccepteerd door programmeurs, die deze RESTful web services gebruiken om de prestaties van hun apps en sites te verbeteren. AppMaster vergemakkelijkt de samenwerking en maakt het gemakkelijker om API's te bouwen, zodat u dit sneller kunt doen.
Waar worden REST API's voor gebruikt?
Een van de belangrijkste voordelen van RESTful webservices is dat het veel flexibiliteit biedt, waardoor u deze RESTful API effectiever kunt gebruiken. Hieronder staan enkele voorbeelden van waar REST API's voor gebruikt worden.
Cloud-gebaseerde toepassingen
Door de stateloosheid van zijn aanroepen zijn REST API's voordelig in cloud-applicaties. Stateloze modules kunnen gemakkelijk opnieuw worden geïnstalleerd en groeien om aan de capaciteitsbehoefte te voldoen als er iets misgaat. Een softwareprogramma dat lokaal en op internet gebaseerde componenten combineert, is een cloud-applicatie. Dit paradigma maakt gebruik van verre servers die toegankelijk zijn via een webbrowser en lopende internetwebdiensten om instructies uit te voeren.
De traditionele locatie van hosts voor cloud-toepassingen is een verafgelegen computersysteem dat wordt beheerd door een externe exploitant van een cloud computing-netwerk. Mail, het delen en opslaan van documenten, orderinvoer, voorraadbeheer, Microsoft Word, customer relationships management(CRM), het verzamelen van informatie, en financiën en boekhouding zijn voorbeelden van taken die met cloud-toepassingen worden uitgevoerd.
REST Applications programming interfaces(API's) kunnen worden gebruikt om externe informatiebronnen en opslagbronnen met elkaar te verbinden. Programmeurs kunnen cloud-apps kleiner maken met behulp van REST API's om gegevens over te dragen aan andere programma's voor het verwerken of analyseren van berekeningen en het terugsturen van de bevindingen naar het softwareprogramma. Geteste API's dwingen actieve uniformiteit af, wat de productie kan versnellen en echte resultaten kan opleveren.
Een goed voorbeeld van een cloud-toepassing is Google Docs of Office 365. Alles wat u voor Google Docs of Office 365 nodig hebt, is een computer die zoekmachines en internetwebdiensten kan draaien. Computernetwerken zorgen voor de gebruikersinterface en de handelingen, inclusief de opslag van informatie. Tal van verschillende cloud apps kunnen door uw bedrijf worden gehost met behulp van cloud applicatie hosts.
Cloud-diensten
Aangezien u moet beheren hoe de URL wordt verwerkt om via een API verbinding te maken met een bron, zijn REST-API's ook nuttig voor cloudwebdiensten. RESTful web services architectuur zal nu waarschijnlijk standaard worden in de toekomst als gevolg van cloud applicaties. Programmeurs gebruiken RESTful web services om verbinding te maken met cloud services via het internet. Een ontwikkelaar maakt code die de API van de internetprovider gebruikt, geeft de nodige inputs en variabelen, en controleert vervolgens het antwoord om er zeker van te zijn dat de actie werkt zoals verwacht.
Eindgebruikers kunnen via een clouddienst als RESTful web services toegang krijgen tot client applicaties of webdiensten die door cloud web services worden aangeboden, zoals rekeninfrastructuur, opslagsystemen of volgsystemen. API's beschrijven de mogelijkheden en operaties van een toepassing en de specifieke vereisten om deze uit te voeren. Om de privacy en veiligheid van de klant te waarborgen, zijn API's vaak afhankelijk van REST of Simple Object Access Protocol (SOAP) interoperabiliteit en toestemmingsmechanismen zoals OAuth 2.0.
Allerlei webdiensten worden "cloud services" genoemd en worden op verzoek online beschikbaar gesteld aan bedrijven en consumenten. Deze webdiensten zijn gecreëerd om snelle, goedkope toegang te bieden tot tools en apps zonder de noodzaak van hardware of infrastructuur. De meeste medewerkers gebruiken cloud webdiensten voor alles van e-mail tot het samenwerken aan documenten.
Webgebruik
Deze web-API's kunnen worden verkregen via een webproject van de gebruiker, een iPhone-app, een IoT-apparaat of een Windows Mobile, aangezien REST niet afhankelijk is van functionaliteit aan de clientzijde. U kunt de architectuur voor uw bedrijf creëren zonder gebonden te zijn aan een specifiek client-side framework.
Een REST API-voorbeeld
Laten we een REST API-voorbeeld bespreken. Klik op de onderstaande link om de Open Trivia Database een willekeurige intelligentievraag te stellen: Dergelijke RESTful web services werden gebruikt om een publieke web API aan te bieden. Je computer toont een eenmalige quizvraag en de antwoorden daarop in JSON-formaat.
Met een HTTP browser, zoals url, zou je de volgende vraag kunnen stellen en een antwoord ontvangen in de respons body: https://opentdb.com/api.php?amount=1&category=18
Het antwoordlichaam van het XML-bestand van de webservice zal alle informatie over de werknemer bevatten.
Alle veelgebruikte programmeerdialecten en ontwikkelaarstools hebben HTTP-clientbibliotheken, zoals retrieve in JavaScript, Node.js en Deno en file get contents() in PHP. Een JSON antwoord kan worden gelezen en gebruikt omdat het machinaal leesbaar is voordat het wordt weergegeven in HTML of een andere stijl.
De Rest en REST API's
In de loop der tijd zijn er veel methoden voor gegevensoverdracht ontwikkeld. Je bent misschien keuzes tegengekomen als CORBA, SOAP, of XML-RPC. De meeste ontwikkelden strikte berichtrichtlijnen. Roy Fielding schetste in 2000 voor het eerst REST, dat veel eenvoudiger is dan de andere.
Het is eerder een verzameling suggesties en beperkingen voor RESTful web services dan een norm. Deze bestaan uit de volgende architecturale beperkingen:
Client-Server-partitie
De clients en webservers kunnen onder de REST-architectuur slechts in één richting communiceren: de client verzoekt de domeincontroller, en de controller of server antwoordt op het verzoek. Webservers kunnen geen verzoeken indienen, en klanten kunnen niet reageren; de consument start alle verbindingen.
RESTful web services houden de klanten en servers geïsoleerd door de interactie tussen hen te vergemakkelijken. Klanten kunnen zich ontwikkelen zonder bang te zijn een andere hosting te beïnvloeden, en servermateriaal kan worden gewijzigd zonder ongewild de klanten te beïnvloeden.
Uniforme interface
Volgens deze strategie moeten alle vragen en reacties zich houden aan een standaard proweb procedure of hun berichten stijlen. Apps en servers worden ontwikkeld in verschillende programmeertalen die onderling slecht presteren met een mediator. Een uniforme interface is een dialect dat elke klant kan gebruiken voor interactie met alle REST API's.
Het vertalen van verzoeken en reacties tussen applicaties met genormaliseerde interactie zou alleen mogelijk zijn. Kleine verschillen zouden door elkaar lopen en informatie verliezen, en oplossingen zullen hun verzoekprocedures moeten aanpassen wanneer web-API's die van hen wijzigen. Een consistente interface elimineert dit vooruitzicht.
TOEGANG TOT https://www.googleapis.com/youtube/v3/channels?part=contentDetails
Zoals alle REST Client-toepassingen bevat dit voorstel twee gegevens. De HTTP-techniek is GET. Deze beschrijft de actie die de client wil ondernemen op de bronnen. Een gebruiker kan vier fundamentele HTTP-methoden gebruiken:
HTTP, of Hyper-Text Transfer Protocol, is de universele taal voor de meeste REST API's. HTTP is niet ontworpen met REST in gedachten. Bovendien aanvaardde REST deze gegevensoverdracht als het criterium voor REST-bewuste apps. Voor het gebruik van HTTP met REST API's dient de client een verzoek in in een formaat dat u wellicht kent. Een videosignaalaanvraag aan de YouTube API ziet er bijvoorbeeld zo uit:
- Gebruik het GET-commando om een bron te verkrijgen.
- Gebruik de POST opdracht om een nieuwe bron aan te maken
- Gebruik de PUT opdracht om wijzigingen aan te brengen in een bestaande bron of deze te blijven bijwerken
- Gebruik de DELETE opdracht om van een bron af te komen.
HTTP-methoden specificeren de beoogde actie die moet worden ondernomen met betrekking tot een specifieke bron. HTTP-methoden staan ook bekend als HTTB-werkwoorden.
De URL is HTTP
De uniform resource identifier, of URI, die de beoogde bron identificeert, staat in de URL. De URL is in dit scenario ook een eindpunt, aangezien dit het punt is waar de RESTful API in contact komt met de gebruiker van de dienst.
Query string: De URL bevat een querystring. De querystring wordt gebruikt om de parameters te definiëren, die waarden krijgen.
Na ontvangst en verificatie van het pleidooi stuurt de webserver gegevens terug over de beoogde bron. Gewoonlijk worden de gegevens teruggestuurd in een structuur die bekend staat als JSON (JavaScript Object Notation). JSON presenteert alle componenten van een bron in een draagbaar formaat dat Humans gemakkelijk kan lezen.
Beginselen van de uniforme interface
De uniforme interface moet de volgende parameters volgen:
HATEOAS: Hypermedia als de motor van de toepassing staat
Hypermedia is de motor achter RESTful web services. Dit geeft aan dat hypermedia alles is wat de klant wil begrijpen om het antwoord van de provider te herkennen.
- Alleen de eerste URI van de clienttoepassing moet aan de client worden verstrekt. De clienttoepassing moet voortdurend alle andere materialen en activiteiten aansturen met behulp van hyperlinks.
- RESTful web services vereisen geen input query language (IDL), wat verschilt van andere API's.
Een mediatype is een naam voor het gegevensformaat van een representatie. Het mediatype geeft een definitie die aangeeft hoe een weergave moet worden behandeld. Een web API die REST gebruikt lijkt op hypertekst. Elk gegevensitem dat kan worden aangesproken draagt een locatie, hetzij direct (zoals via link- en identiteitseigenschappen), hetzij impliciet (bijvoorbeeld afgeleid van de beschrijvingstructuur van het mediatype).
Zelfbeschrijvende berichten
Elke communicatie tussen de client en de server moet voldoende gegevens opleveren om de communicatie uit te voeren. Daarom moet het verzoek van de client naar de server de bron specificeren waartoe hij toegang probeert te krijgen, samen met zijn specifieke doelstellingen.
Bovendien moeten bronafbeeldingen zelfbeschrijvend zijn; de gebruiker hoeft niet te weten of een bron een persoon of een apparaat is. In plaats daarvan moet hij reageren volgens het mediatype dat met de hulpbron verbonden is.
Daarom zullen we ongetwijfeld vele unieke mediatypes ontwikkelen, vaak één mediatype per bron. Elke vorm van media specificeert een standaard productieparadigma. HTML bijvoorbeeld definieert hoe hypertekst wordt weergegeven en hoe de browser elk onderdeel behandelt.Identificatie van de hulpbronnen
De bronnen waarnaar in de achterliggende communicatie tussen de klant en de server wordt verwezen, moeten herkenbaar zijn aan de hand van afbeeldingen. Het vasthouden aan het Uniform Resource Identifier (URI) systeem maakte dit mogelijk. Met andere woorden, de communicatie van de server naar de klant kan een HTML-versie van het document en wat informatie bevatten in plaats van het echte bestand uit de opslag van de server.
De consument kan de HTML-versie gemakkelijk begrijpen omdat deze het URI-patroon volgt. De klant moet bronnen aanpassen door de server een voorstelling te geven van hoe de bron er uiteindelijk moet uitzien. Zo kan de gebruiker resources bouwen, ophalen, wijzigen en verwijderen. Als de klant de nodige autorisatie heeft om de gegevens te wijzigen, moet de server de vraag vervullen.
Start FreeTry AppMaster no-code today!Platform can build any web, mobile or backend application 10x faster and 3x cheaper
Staatloos
Bij een RESTful API moeten alle clientverzoeken van voorbijgaande aard zijn. Bijgevolg bevatten elke query en response body alle gegevens die nodig zijn om het contract te sluiten, waardoor elke verbinding autonoom is. De server houdt eerdere HTTP-verzoeken niet bij; hij behandelt elk verzoek van de client als een volledig nieuwe query.
Aangezien de server geen extra taken hoeft uit te voeren om historische gegevens te verkrijgen, beperken stateless transporten de hoeveelheid opslag die de server nodig heeft aanzienlijk en vergroten zij de kans dat een antwoord aanvaardbaar is. Dit garandeert de schaalbaarheid van deze interacties: programmeurs hoeven zich geen zorgen te maken over het gebruik van veel meer opslagruimte of het belasten van de server wanneer hun software uitbreidt en HTTP-verzoeken doet.
Gelaagd
We hebben tot nu toe web API queries gedefinieerd als een rechttoe rechtaan client-server uitwisseling, hoewel dit een beetje overdreven is. Tussen deze twee zijn er vaak meer servers. Deze platforms, of lagen, zijn er om het verkeer te beheren en te verspreiden, bescherming toe te voegen, en diverse andere cruciale taken uit te voeren.
Volgens dit concept moeten berichten die worden verzonden tussen een gebruiker en een doelserver op dezelfde manier worden gestructureerd en behandeld, ongeacht de lagen die ertussen liggen. Extra lagen moeten in orde zijn met klantinteracties. Programmeurs die zich aan deze regel houden, kunnen serversystemen veranderen zonder het fundamentele request-response proces te beïnvloeden.
Cacheerbare
Caching treedt op wanneer een klant op een website surft en de inhoud wordt opgeslagen op de machine van de klant. Het materiaal in de cache wordt snel geladen uit het interne geheugen in plaats van opnieuw te worden gedownload van de server wanneer een gebruiker die site later bezoekt. De meeste grote sites gebruiken caching om de belasting van pagina's te verminderen en tegelijkertijd serverruimte en bandbreedte te sparen.
Data caching wordt overwogen bij de ontwikkeling van REST API's. Het antwoord dat een server aan een klant geeft, moet vermelden of en hoe lang de gegeven bron kan worden opgeslagen.
Code op aanvraag
Het laatste REST principe is overbodig. Op verzoek kan het antwoord van een API softwarecode bevatten die de klant kan gebruiken. Hierdoor kan de klant de clienttoepassing of het programma in zijn backend uitvoeren.
Een API wordt beschouwd als een RESTful API als hij voldoet aan deze reeks richtlijnen. Deze richtlijnen geven programmeurs echter veel vrijheid om de functies van hun RESTful API aan te passen. REST API's verschillen van het Simple Object Access Protocol, een andere populaire web API techniek, doordat ze flexibeler zijn (SOAP).
Overeenstemming over eindpunten
Houd rekening met deze eindpunten:
- /user/123\s
- /user/id/123\s
- /user/123\s/user/id/123\s
- /user/?id=123
Dit zijn allemaal legitieme methoden voor client 123 om gegevens op te halen. Bij ingewikkelder procedures groeit het aantal mogelijkheden. Bijvoorbeeld, in omgekeerde volgorde te beginnen bij entry 51, 10 personen weergeven met achternamen die beginnen met "A" en werkzaam zijn voor het bedrijf.
Uiteindelijk maakt het niet uit hoe je URL's structureert; uniformiteit in je RESTful API is belangrijk. Op enorme softwaresystemen met veel programmeurs kan dat niet eenvoudig zijn. RESTful API-aanpassingen zijn onvermijdelijk, maar endpoint URL's mogen nooit worden afgekeurd, omdat de apps die erop vertrouwen dan niet meer werken.
REST API versiebeheer
Het versieren van API's is een gebruikelijke praktijk om incompatibiliteiten te voorkomen. Ter illustratie: /2.0/user/123 vervangt /user/123. De oude en nieuwe eindpunten kunnen beide blijven functioneren. Bijgevolg moeten belangrijke API's uit het verleden behouden blijven. Vorige versies kunnen uiteindelijk worden ingetrokken, maar de procedure moet zorgvuldig worden doordacht.
REST API-authenticatie
Elk apparaat kan zonder autorisatie een quip downloaden via de opvraag-API. De API's die privé-informatie lezen of het bewerken en verwijderen van queries mogelijk maken, ondersteunen dit niet. Client-side programma's binnen hetzelfde domein als de RESTful webservices worden op dezelfde manier als HTTP-verzoeken cookies verzonden en ontvangen. (Merk op dat de privileges restart optie moet worden gespecificeerd in eerdere sites voor Fetch().) Een API-vraag kan worden geverifieerd om te bevestigen dat een gebruiker is aangemeld en de vereiste machtigingen heeft.
HTTP basis authenticatie: Programma's van derden moeten verschillende goedkeuringsoplossingen gebruiken. Enkele populaire authenticatiemethoden zijn primaire verificatie voor:
- HTTP. Een base64-gecodeerde gebruikersnaam: wachtwoordstring wordt gegeven in het queryveld als onderdeel van een HTTP-goedkeuringsheader.
- API-sleutels: Door het verstrekken van een RESTful API-sleutel die speciale machtigingen kan hebben of beperkt kan zijn tot een enkele site, wordt een API beschikbaar gemaakt voor toepassingen van derden. Elk bericht bevat de sleutel in de querystring of in de HTTP-header. (De querystring is een onderdeel van de URL).
- OAuth: Alvorens verzoeken te doen, worden een klant-ID en eventueel een klant-geheim naar een OAuth-server gestuurd om een geloofsbrief te verkrijgen. Tot de vervaldatum wordt de OAuth-identiteit vervolgens samen met elk API-verzoek verzonden.
- Internet tokens in JSON (JWT): De query header en de response header brengen veilig digitaal ondertekende gebruikersreferenties over. Met JWT's kan de server toegangsrechten versleutelen, waardoor het niet meer nodig is een database te bevragen of een ander authenticatiemechanisme te gebruiken.
Het gebruiksscenario bepaalt hoe een API wordt geauthenticeerd:
- Soms wordt een programma van een derde partij behandeld als elke andere ingelogde client met dezelfde privileges en rechten. Een kaart-API kan bijvoorbeeld een verzoekend programma instructies geven tussen twee plaatsen. Het moet controleren of het programma een legitieme gebruiker is, maar het hoeft de referenties van de client niet te controleren.
- In andere situaties vraagt het programma van een derde partij om persoonlijke informatie van een specifieke gebruiker, zoals de inhoud van een e-mail. De REST API's moeten de client en zijn machtigingen herkennen, maar hoeven zich niet bezig te houden met het aanroepende programma.
REST API Beveiliging
RESTful web services voegen een extra manier toe om te communiceren met en invloed uit te oefenen op uw software. Zelfs als uw host geen verhoogd hackersdoel is, zou een zich misdragende gebruiker honderden verzoeken per seconde kunnen indienen en het kunnen laten instorten. Dit artikel gaat niet over beveiliging, maar over standaard beste procedures:
Maak gebruik van HTTPS
Gebruik een sterk authenticatiemechanisme
CORS kan worden gebruikt om oproepen van klanten te beperken tot bepaalde gebieden.
Zorg voor de noodzakelijke mogelijkheden - dat wil zeggen, niet
Maak geen DELETE keuzes die niet nodig zijn; controleer alle Endpoint URL's en body informatie.
Blokkeer links van niet-geïdentificeerde sectoren of IP-adressen door geen API-vouchers in client-side JavaScript op te nemen.
Abnormaal grote pakketten worden geblokkeerd.
Denk aan rate restriction, waarbij verzoeken van hetzelfde IP-adres of API-credential worden beperkt tot N queries per minuut.
Antwoord met de juiste HTTP-statuscode, logboekquery's in de cache-header, en onsuccesvol onderzoek.
Meerdere verzoeken en onnodige gegevens
De inzet van RESTful web services heeft beperkingen. Het is mogelijk dat een antwoord meer informatie bevat dan gevraagd of dat er meerdere verzoeken nodig zijn om alle informatie te krijgen. Denk aan RESTful webservices die gebruikers toegang geven tot creator- en boekinformatie; de client zou kunnen:
- Vragen om de informatie van de eerste 10 boeken, in volgorde van aankoop (topverkoper eerst). Een verzameling boeken, samen met de ID van elke schrijver, wordt opgenomen in het antwoord.
Om de informatie voor elke schrijver op te halen, maak je tot 10 /author/id queries.
Voor elk antwoord op de bovenliggende query moeten N API queries worden gegenereerd, gekarakteriseerd als het "N+1 probleem."
Als dit een frequent gebruikte situatie is, kunnen de RESTful web services worden aangepast om alle informatie over de schrijver op te nemen voor elk boek dat het heeft geproduceerd, inclusief naam, geslacht, nationaliteit, biografie, enzovoort. Zelfs meer informatie over hun vorige boeken kan worden verstrekt, hoewel dit de responslast aanzienlijk zou verhogen. De API kan worden gewijzigd om informatie over de schrijver optioneel te maken. Author details=full om onnodig grote antwoorden te voorkomen. Alleen al het aantal opties dat API-ontwerpers moeten ondersteunen kan overweldigend zijn.
Inpakken
Je begrijpt nu grondig REST API's, hoe REST API's werken, REST API voorbeelden, waar REST API's voor gebruikt worden, architectonische beperkingen, en andere onderwerpen die in deze tutorial behandeld zijn. Programmeurs vinden het leren over API's soms moeilijk en intimiderend, maar no-code platform AppMaster heeft een nieuwe toegankelijke REST API's bibliotheek gecreëerd waar u uw kennis van een reeks REST API's kunt verdiepen ter ondersteuning van uw verdere professionele ontwikkeling.
Bij AppMaster proberen we de toegankelijkheid en bruikbaarheid van API's te vergroten. We willen dat je leert over, experimenteert met en je de voordelen realiseert van het gebruik van API-software in je carrière en persoonlijke leven. Om u te helpen sneller betere web-API's te ontwerpen, verbetert AppMaster de samenwerking en automatiseert het elke fase van de API-levenscyclus. Blijf REST API's creëren, bevorderen en uw begrip ervan verbreden.
