Share
Als u enige tijd met moderne webontwikkeling hebt doorgebracht, zult u termen als REST en API tegenkomen. Als u van deze voorwaarden hebt gehoord of met API's werkt, maar geen volledig inzicht hebt in hoe ze werken of hoe u uw eigen API kunt bouwen, is deze serie voor u.
In deze zelfstudiereeks beginnen we met een overzicht van REST-principes en -concepten. Vervolgens gaan we door met het maken van onze eigen volwaardige API die wordt uitgevoerd op een Node.js Express-server en verbinding maakt met een MySQL-database. Nadat u deze serie hebt voltooid, moet u er zeker van zijn dat u uw eigen API bouwt of dat u zich verdiept in de documentatie van een bestaande API.
Om het beste uit deze tutorial te halen, zou je al enige basiskennis van de commandoregel moeten hebben, de grondbeginselen van JavaScript kennen en Node.js wereldwijd geïnstalleerd moeten hebben.
Vertegenwoordiging door de staat, of RUST UIT, beschrijft een architecturale stijl voor webservices. REST bestaat uit een reeks normen of beperkingen voor het delen van gegevens tussen verschillende systemen en systemen die REST implementeren zijn bekend als RESTful. REST is een abstract concept, geen taal, raamwerk of type software.
Een losse analogie voor REST zou een verzameling vinyl bevatten versus een streaming muziekdienst. Met de fysieke vinylverzameling moet elk record in zijn geheel worden gedupliceerd om kopieën te delen en te distribueren. Met een streamingservice kan dezelfde muziek echter eeuwig worden gedeeld via een verwijzing naar bepaalde gegevens, zoals de titel van een nummer. In dit geval is de muziekstreaming een RESTful-service en is de vinylcollectie een niet-RESTVOLLE service.
Een API is een Application Programming Interface, een interface waarmee softwareprogramma's met elkaar kunnen communiceren. EEN RESTful API is gewoon een API die voldoet aan de principes en beperkingen van REST. In een web-API ontvangt een server een verzoek via een URL-eindpunt en verzendt een antwoord in ruil daarvoor, wat vaak data in een formaat zoals JSON is.
Zes leidende beperkingen definiëren de REST-architectuur, hieronder beschreven.
U zult al bekend zijn met het feit dat alle websites URL's hebben die beginnen http (of https voor de beveiligde versie). HyperText Transfer Protocol, of HTTP, is de communicatiemethode tussen clients en servers op internet.
We zien dit het duidelijkst in de URL-balk van onze browsers, maar HTTP kan worden gebruikt voor meer dan alleen het aanvragen van websites van servers. Wanneer u naar een URL op internet gaat, doet u eigenlijk een KRIJGEN verzoek om die specifieke bron, en de website die u ziet, is de hoofdtekst van de reactie. We gaan over KRIJGEN en andere soorten verzoeken binnenkort.
HTTP werkt door een a te openen TCP (Transmission Control Protocol) -verbinding met een serverpoort (80 voor http, 443 voor https) om een verzoek in te dienen, en de luister-server antwoordt met een status en een lichaam.
Een verzoek moet bestaan uit een URL, een methode, koptekstinformatie en een hoofdtekst.
Er zijn vier belangrijke HTTP-methoden, ook wel HTTP-werkwoorden genoemd, die vaak worden gebruikt voor interactie met web-API's. Deze methoden bepalen de actie die met een bepaalde resource zal worden uitgevoerd.
HTTP-verzoekmethoden komen losjes overeen met het paradigma van CRUD, wat staat voor Maken, bijwerken, lezen, verwijderen. Hoewel CRUD verwijst naar functies die worden gebruikt in databasebewerkingen, kunnen we die ontwerpprincipes toepassen op HTTP-werkwoorden in een RESTful API.
| Actie | Verzoek methode | Definitie |
|---|---|---|
| Lezen | KRIJGEN | Haalt een resource op |
| creëren | POST | Creëert een nieuwe bron |
| Bijwerken | LEGGEN | Werkt een bestaande bron bij |
| Verwijder | DELETE | Wist een resource |
KRIJGEN is een veilige, alleen-lezen bewerking die de status van een server niet verandert. Elke keer dat u op een URL in uw browser klikt, zoals https://www.google.com, je stuurt een KRIJGEN verzoek aan de servers van Google.
POST wordt gebruikt om een nieuwe bron te maken. Een bekend voorbeeld van POST meldt zich aan als gebruiker op een website of app. Na het verzenden van het formulier, POST verzoek met de gebruikersgegevens kan worden verzonden naar de server, die deze informatie vervolgens in een database zal schrijven.
LEGGEN werkt een bestaande bron bij, die kan worden gebruikt om de instellingen van een bestaande gebruiker te bewerken. anders POST, LEGGEN is idempotent, wat betekent dat dezelfde oproep meerdere keren kan worden gemaakt zonder een ander resultaat te produceren. Bijvoorbeeld als u hetzelfde heeft verzonden POST verzoek om meerdere keren een nieuwe gebruiker in een database aan te maken, zou het een nieuwe gebruiker creëren met dezelfde gegevens voor elk verzoek dat u deed. Echter hetzelfde gebruiken LEGGEN een verzoek aan dezelfde gebruiker zou voortdurend hetzelfde resultaat opleveren.
DELETE, zoals de naam al doet vermoeden, zal eenvoudigweg een bestaande bron verwijderen.
Zodra een verzoek van de client naar de server wordt doorgestuurd, stuurt de server een HTTP-antwoord terug, dat metagegevens bevat over het antwoord dat bekend staat als headers, evenals het hoofdgedeelte. Het eerste en belangrijkste deel van het antwoord is de status code, die aangeeft of een verzoek succesvol was, of er een fout was, of dat een andere actie moet worden ondernomen.
De meest bekende antwoordcode die u bekend zult zijn, is 404, wat betekent Niet gevonden. 404 maakt deel uit van de 4xx klasse statuscodes, die clientfouten aangeven. Er zijn vijf klassen statuscodes die elk een reeks antwoorden bevatten.
Accentsconagua
1xx: Informatie2xx: Succes3xx: Omleiding4xx: Cliëntfout5xx: ServerfoutAndere veel voorkomende reacties die u misschien kent, zijn 301 is permanent verhuist, die wordt gebruikt om websites om te leiden naar nieuwe URL's, en 500 Interne server fout, Dit is een fout die vaak wordt weergegeven als er iets onverwachts is gebeurd op een server waardoor het niet mogelijk is om aan het beoogde verzoek te voldoen.
Met betrekking tot RESTful API's en de bijbehorende HTTP-werkwoorden moeten alle antwoorden in de 2xx reeks.
| Verzoek | antwoord |
|---|---|
KRIJGEN | 200 (OK) |
POST | 201 (Gemaakt) |
LEGGEN | 200 (OK) |
DELETE | 200 (OK), 202 (Geaccepteerd), of 204 (Geen inhoud) |
200 OK is het antwoord dat aangeeft dat een verzoek succesvol is. Het wordt gebruikt als een antwoord bij het verzenden van een KRIJGEN of LEGGEN verzoek. POST zal terugkeren a 201 Gemaakt om aan te geven dat een nieuwe bron is gemaakt, en DELETE heeft enkele aanvaardbare antwoorden, die aangeven dat het verzoek is aanvaard (202), of er is geen inhoud die moet worden geretourneerd omdat de bron niet langer bestaat (204).
We kunnen de statuscode van een resourceaanvraag testen met behulp van cURL, een opdrachtregelprogramma dat wordt gebruikt voor het overbrengen van gegevens via URL's. Gebruik makend van Krul, gevolgd door de -ik of --omvatten vlag, stuurt een KRIJGEN verzoek om een URL en de headers en body weergeven. We kunnen dit testen door het opdrachtregelprogramma te openen en cURL met Google te testen.
krul -i https://www.google.com De server van Google reageert met het volgende.
HTTP / 2 200 date: di, 14 aug 2018 05:15:40 GMT verloopt: -1 cache-control: private, max-age = 0 content-type: text / html; charset = ISO-8859-1 ...
Zoals we kunnen zien, de Krul request retourneert meerdere headers en de volledige HTML-body van het antwoord. Omdat het verzoek goed is verlopen, is het eerste deel van het antwoord het 200 statuscode, samen met de versie van HTTP (dit is HTTP / 1.1 of HTTP / 2).
Aangezien dit specifieke verzoek een website retourneert, is de inhoudstype (MIME-type) wordt geretourneerd text / html. In een RESTful API zult u waarschijnlijk zien application / json om aan te geven dat het antwoord JSON is.
Interessant is dat we een ander type antwoord kunnen zien door een iets andere URL in te voeren. Doe een Krul op Google zonder de www.
krul -i https://google.com Locatie HTTP / 2 301: https://www.google.com/ inhoudstype: text / html; charset = UTF-8
Google-omleidingen google.com naar www.google.com, en gebruikt een 301 antwoord om aan te geven dat de bron moet worden omgeleid.
Wanneer een API op een server wordt gemaakt, zijn de gegevens die deze bevat toegankelijk via eindpunten. Een eindpunt is de URL van het verzoek dat het kan accepteren en verwerken KRIJGEN, POST, LEGGEN, of DELETE verzoek.
Een API-URL bestaat uit de root-, pad- en optionele queryreeks.
https://api.example.com of https://api.example.com/v2: De root van de API, die kan bestaan uit het protocol, het domein en de versie./ Users /of / Users / 5: Unieke locatie van de specifieke resource.?location = chicago & age = 29: Optionele sleutelwaardeparen die worden gebruikt voor sorteren, filteren en paginering.begrenzing om de antwoorden te filteren om slechts tien resultaten te bevatten.https://api.example.com/users?limit=10
Over het algemeen verwijzen mensen naar een API als een RESTful API naar de naamgevingsconventies die worden gebruikt voor het maken van API-URL-eindpunten. Enkele belangrijke conventies voor een standaard RESTful API zijn als volgt:
5, we zouden gebruiken / Users / 5, niet / User / 5..json.toevoegen en verwijderen mag niet worden weergegeven in een REST-URL. Om een nieuwe gebruiker toe te voegen, zou je gewoon een POST verzoek om / gebruikers, niet zoiets / Users / add. De API moet worden ontwikkeld om meerdere typen verzoeken aan dezelfde URL te verwerken.Al deze conventies zijn richtlijnen, omdat er geen strikte REST-normen volgen. Het gebruik van deze richtlijnen maakt uw API echter consistent, vertrouwd en gemakkelijk te lezen en te begrijpen.
In dit artikel hebben we geleerd wat REST en RESTful API's zijn, hoe HTTP-verzoekmethoden en reactiecodes werken, de structuur van een API-URL en veelgebruikte RESTful API-conventies. In de volgende tutorial zullen we leren hoe we al deze theorie kunnen gebruiken door een Express-server met Node.js op te zetten en onze eigen API te bouwen..
