Extern API-verzoek

Niet te veel theorie?

Laten we dit in praktijk brengen. Laten we AppMaster openen, er een API-verzoek mee aanmaken, en beter begrijpen hoe dit verzoek werkt.

Aanmaken van een extern API-verzoek

API-verzoeken worden aangemaakt in de sectie "Bedrijfslogica", in het tabblad "Externe API-verzoeken".

Het is tijd om te klikken op "+ Nieuw API Verzoek".

De naam en beschrijving kunnen op alles worden ingesteld, ze zijn alleen voor persoonlijk gebruik.

Laten we ons bezighouden met de gegevens die er echt toe doen.

Het minimum dat nodig is om een verzoek te creëren is het specificeren van de methode en het adres (URL). Laten we beginnen met de laatste.

URL

URL - Uniform Resource Locator. Een adres dat wordt gegeven aan een bepaalde bron op het internet. De meest bekende versie van zo'n bron is een HTML-pagina - we voeren de URL in de adresbalk van de browser in en openen de gewenste site. Tegelijkertijd kan de bron zelf van alles zijn, een foto, een video, een dataset. Het belangrijkste is dat deze bron een specifieke pointer heeft - een URL waarnaar je een verzoek kunt sturen om deze bron te verkrijgen.

Methoden

Verwijzend naar de gegevens op het adres ervan, geven we ook de methode (je kunt ook zeggen het type) van het verzoek aan, dat wil zeggen, we geven aan wat er eigenlijk met deze gegevens moet gebeuren.

Toen we verzoeken verstuurden voor de taak van de eerste module, ontvingen we gegevens. Dit is de GET-methode. Deze methode is de meest voor de hand liggende en ook de enige vereiste. Daarom werd, zelfs als we het niet expliciet specificeerden, toch standaard aangenomen dat dit GET was.

Laten we eens kijken welke andere methoden er zijn.

De HTTP-standaard zelf stelt geen beperkingen aan het aantal methoden dat kan worden gebruikt. Tegelijkertijd worden nog slechts enkele van de meest standaardmethoden gebruikt om de compatibiliteit te behouden. Er zijn 5 verschillende methoden die kunnen worden gebruikt in de AppMaster API requests.

GET. Deze is al behandeld. De methode vraagt de beschikbaarstelling van een bron, en ontvangt gegevens.

POST. Om gegevens ergens vandaan te halen, moet je deze gegevens eerst daar plaatsen. De POST methode doet precies dat. Stuurt gegevens naar de server, creëert een bron.

PUT. Vergelijkbaar met de POST methode, maar de taak is om de gegevens bij te werken. Het creëert geen nieuwe gegevens, maar vervangt bestaande gegevens, werkt ze bij.

DELETE. Zoals de naam al aangeeft, worden hiermee gegevens verwijderd.

PATCH. Deze methode is vergelijkbaar met PUT, maar wordt gebruikt om de gegevens gedeeltelijk bij te werken, in plaats van ze volledig te vervangen. Met de methode PATCH kunt u bijvoorbeeld de titel van een artikel wijzigen, of de waarde van een parameter veranderen.

Het is belangrijk te bedenken dat de server helemaal niet hoeft te doen wat in de methode wordt gespecificeerd. We kunnen het adres van een pagina sturen met de methode DELETE, maar dat betekent niet dat de server die pagina ook daadwerkelijk verwijdert. Maar, puur theoretisch, kan hij dit doen met het GET commando. Of niets veranderen, maar tegelijkertijd gegevens versturen als antwoord op POST. Gewoon omdat de ontwikkelaar het zo geconfigureerd heeft.

Dit is waar REST om de hoek komt kijken, die zegt dat het tijd is om af te spreken dat de opdracht wordt nageleefd, de rommel te stoppen en precies te doen wat in de methode wordt aangegeven. Dit zou op zijn minst de hoofdtaak moeten zijn (hoewel niet noodzakelijkerwijs de enige). Bijvoorbeeld, wanneer je de inhoud van een artikel overbrengt met de GET-methode, kun je tegelijkertijd de teller van het aantal weergaven ervan met 1 verhogen.

Zo, we hebben uitgezocht waar de gegevens zich bevinden en wat ermee gedaan kan worden. Laten we verder gaan en kijken welke andere componenten het verzoek kan hebben.

URL Params

URL Params. Er zijn situaties waarin we slechts een deel van de URL kennen. Een voorbeeld zijn de artikelen op de Appmaster.io website. Het startadres voor alle artikelen is hetzelfde - https://appmaster.io/blog/. Maar vervolgens heeft elk artikel zijn eigen titel en dus zijn eigen individuele deel voor de exacte aanduiding van dit specifieke artikel.

In een dergelijke situatie worden URL-params gebruikt. We schrijven meteen het algemene deel voor, en laten de rest over aan het proces. Het resultaat is dat de URL wordt geschreven in de vorm https://appmaster.io/blog/:id/

Het bekende deel wordt geschreven zoals het is, en het variabele deel wordt geplaatst na het ":" teken. De naam van dit variabele deel (reeds zonder ":") wordt toegevoegd aan de lijst van parameters. In dit geval kunnen er meerdere variabele delen zijn, en hun plaats is overal in de URL.

Query Params

Query Params. Weet je nog dat we in de eerste module een verzoek stuurden naar boredapi.com? En naast het adres werden er extra gegevens voorgeschreven. Dat waren de Query Params.

Ze worden na de URL geschreven en daarvan gescheiden door een "?" teken. De naam van de parameter, het teken "=" en de waarde van de parameter zelf worden aangegeven. Als meerdere parameters tegelijk worden gebruikt, worden ze gescheiden door het teken "&".

Bij het specificeren van parameters in AppMaster hoeft u echter niet na te denken over de request-regels. Alles wordt automatisch goed geformatteerd. U hoeft alleen de naam van de parameter zelf op te geven en deze toe te voegen aan de lijst.

Query Params worden gebruikt wanneer de gegevensbron hetzelfde is, maar de gegevens zelf kunnen verschillen. Bijvoorbeeld, Boredapi bevatte een enorme lijst van dingen om te doen. Maar wij waren alleen geïnteresseerd in de dingen die voor één persoon bestemd zijn en dat is wat we in de verzoekparameters hebben gespecificeerd.

Een ander gebruik is het beperken van de hoeveelheid gegevens. We zouden bijvoorbeeld een of andere lijst kunnen opvragen, maar alleen de eerste 5 items ervan opvragen. Deze hoeveelheid kan ook een query parameter zijn.

Een andere optie is een toegangssleutel. U hebt deze optie wellicht gebruikt in module 1 toen u naar Alphavantage verwees. Gegevens konden alleen worden verkregen na registratie en het versturen van een persoonlijke sleutel in de aanvraagparameters.

Let op de pagina's die u bezoekt op het internet, ook daarin vindt u waarschijnlijk diverse parameters. Open bijvoorbeeld de weerpagina van Ventusky.com, in de query parameters worden geografische waarden van lengte- en breedtegraad meegestuurd.

Headers

Headers. Request headers. Meestal bevatten headers service-informatie over het verzoek (meta-informatie). Met headers kan de server meer informatie krijgen over de client die de gegevens opvraagt. De headers kunnen informatie bevatten over welke browser wordt gebruikt, in welke codering het antwoord wordt verwacht, in welke taal, de exacte tijd van het verzoek, en meer. Bij toegang tot beschermde gegevens kunnen de headers een autorisatiesleutel bevatten.

In de meeste gevallen zijn headers optioneel. Zelfs in de eerste module hebben we al een verzoek gedaan waarbij we geen headers hebben opgegeven (hoewel dit niet betekent dat het verzoek daadwerkelijk zonder headers is verzonden).

Body

Body. De body van het verzoek. GET verzoeken doen het meestal zonder, maar als we wat gegevens naar de server willen sturen, een POST of PUT verzoek sturen, dan worden deze gegevens in de request body geplaatst. Tegelijkertijd kun je gegevens van elke complexiteit in de request body plaatsen, bijvoorbeeld een videobestand versturen, en je niet beperken tot een getal of een tekststring.