De basisprincipes van REST en RESTful API Development

Webontwikkelaars praten hier vaak over REST-principes en RESTful data-architectuur, omdat het een cruciaal aspect is van moderne ontwikkeling, maar soms kan het ongelooflijk verwarrend zijn. REST is geen technologie op zich, maar eerder een methode voor het maken van API's met bepaalde organisatieprincipes. Deze principes zijn bedoeld om ontwikkelaars te begeleiden en een meer universele omgeving te creëren voor het verwerken van API-aanvragen.

In deze post wil ik RESTful ontwikkelingspraktijken in vogelvlucht uitleggen. Ik wil pakken de wat liever dan de hoe. Hoewel ik het op beide gebieden zal aanraken, is dit bericht gemaakt voor iedereen die zich bezig houdt met webontwikkeling, maar het concept van REST-API's gewoon niet begrijpt.

REST Voor webontwikkelaars

Het acroniem REST staat voor Representatieve overdracht door de staat. Dit klinkt misschien wat verwarrend, en de wiki-invoer maakt het nog meer verwarrend. Maar het is mogelijk om de terminologie te vereenvoudigen.

REST is slechts een reeks van richtlijnen en architecturale stijlen gebruikt voor gegevensoverdracht. Het wordt vaak toegepast op webapplicaties, maar kan ook gegevens aan software doorgeven.

De acronym API staat voor Application Programming Interface, wat methoden zijn van verbinden met andere bibliotheken of applicaties. Windows heeft meerdere API's en Twitter heeft ook een web-API, hoewel ze verschillende taken met verschillende doelen uitvoeren.

Alles bij elkaar combineren RESTful API's zijn API's die de REST-architectuur volgen.

Wat is precies de REST-architectuur?

Dit is waar het moeilijk is om details vast te leggen. Er zijn echter enkele architectonische constanten, zoals:

• Consistentie in de gehele API
• Staatloos bestaan, d.w.z. geen sessies aan de serverzijde
• Gebruik van HTTP-statuscodes waar passend
• Gebruik van URL-eindpunten met een logische hiërarchie
• Versiebeheer in de URL in plaats van in HTTP-headers

Er zijn geen overdreven specifieke richtlijnen zoals de W3C HTML5-specificatie die tot verwarring zou kunnen leiden, en een miasma van onzekerheid rond REST-terminologie..

Ook de bovenstaande lijst moeten niet als vaste regels worden beschouwd, ook al zijn ze waar voor de meeste moderne RESTful API's.

REST is a lichtgewicht methodiek waardoor het perfect is voor HTTP-gegevens. Daarom werd REST zo populair op internet en daarom wordt het algemeen beschouwd als de beste keuze voor API-ontwikkeling.

Zoals Vinay Sahni het verwoordt, “een API is de gebruikersinterface van een ontwikkelaar.” Alles moet gemakkelijk te gebruiken zijn en een geweldige gebruikerservaring bieden. RESTful API's proberen precies dat te doen.

Key Takeaways voor RESTful API's

Deze tips zijn in de context van API's uitsluitend voor webtoepassingen. Dit betekent dat HTTP is een vereiste, en dat betekent vaak dat de API-gegevens worden op een externe server gehost. Laten we eens kijken hoe RESTful API's aan de kant van de API-gebruiker werken.

De API-gebruiker is de webontwikkelaar die een script kan bouwen dat verbinding maakt met een externe API-server, waarna de benodigde gegevens worden doorgegeven via HTTP. De ontwikkelaar kan vervolgens gegevens op zijn website weergeven zonder persoonlijke toegang tot de externe server te hebben (zoals het trekken van Twitter-gegevens).

Over het algemeen zijn er vier commando's gewend om toegang tot RESTful API's:

1. KRIJGEN voor het ophalen van een object
2. POST voor het maken van een nieuw object
3. LEGGEN voor het wijzigen of vervangen van een object
4. DELETE voor het verwijderen van een object

Elk van deze methoden zou moeten zijn geslaagd met de API-aanroep om de server te vertellen wat te doen.

De overgrote meerderheid van web-API's alleen toestaan KRIJGEN verzoeken om gegevens van een externe server te halen. Verificatie is optioneel, maar zeker een goed idee wanneer mogelijk schadelijke opdrachten zoals LEGGEN of DELETE.

Maar niet veel RESTful API's gaan zelfs zover. Overweeg Pokéapi, een gratis API-database voor Pokémon. Het is open voor het publiek met een fatsoenlijke snelheidsbeperking (het beperken van gebruikers tot een bepaald aantal API-verzoeken gedurende een bepaalde periode), maar staat alleen de KRIJGEN methode voor toegang tot bronnen. Dit kan in de volksmond a worden genoemd API alleen voor consumptie.

Retourtypen zijn ook belangrijk, en zouden ook moeten behoud van homogeniteit voor alle bronnen. JSON is een populair retourtype met online specificaties die de juiste datastructuren uitleggen.

RESTful API's gebruiken zelfstandige naamwoorden voor API-objecten, en werkwoorden voor het uitvoeren van acties op die objecten. Authenticatie kan hier onderdeel van zijn, ook hier kan snelheidsbeperking onderdeel van zijn. Maar een zeer eenvoudige API kan langskomen zonder veel zorg te besteden aan gebruikersbeperkingen.

Toegang tot API-bronnen

Openbare API's zijn meestal toegankelijk via directe webadressen. Dit betekent de URL-structuur is belangrijk, en zou alleen voor API-verzoeken moeten worden gebruikt.

Sommige URL's kunnen een voorvoegmap bevatten zoals / V2 / voor een bijgewerkte versie 2 van een vorige API. Dit is gebruikelijk voor ontwikkelaars die hun 1.x API niet willen depreciëren, maar toch de nieuwste structuur willen aanbieden.

Ik heb echt genoten van deze berichtgeving basis URL-structuren en voorbeelden van andere services.

Merk op dat het eindpunt is retourgegevens zullen veranderen dramatisch gebaseerd op de HTTP-methode. Bijvoorbeeld, KRIJGEN haalt inhoud op, terwijl POST maakt nieuwe inhoud. Het verzoek zou naar hetzelfde eindpunt kunnen verwijzen, maar het resultaat zou heel anders kunnen zijn.

Door online voorbeelden te bekijken, kunt u concepten beter begrijpen. We hebben de Pokeapi al gezien, maar hier zijn er nog meer real-world API-voorbeelden doornemen:

• Reddit API
• GitHub API
• Flickr API
• Pinterest API

Bouw je eigen API

Het proces van het bouwen van uw eigen API moet niet lichtvaardig worden genomen, maar het is ook niet zo ingewikkeld als u misschien denkt. Het duurt een begrip van API-ontwerppatronen en beste praktijken om iets van echte waarde te bouwen.

Elke API moet maak verbinding met uw server om gegevens van een soort terug te sturen. U hoeft niet alleen code te schrijven om dat te doen, maar u moet ook de retourgegevens opmaken. Andere mogelijke vereisten zijn onder meer authenticatie en snelheidsbeperkend, dus het bouwen van een API is zeker niet voor bangeriken.

Maar laten we een kijkje nemen enkele basisprincipes van API-architectuur.

Bouw eindpunten

Een aspect van API-ontwikkeling is eindpunten bouwen. Wanneer middelen creëren je wilt zelfstandige naamwoorden gebruiken, geen werkwoorden. Dit betekent dat API-gegevens een persoon, plaats of ding moeten teruggeven, meestal is dat zo een ding met specifieke kenmerken (bijvoorbeeld een tweet en al zijn metadata).

Het kan moeilijk zijn om zelfstandig naamwoorden te benoemen, maar dit is een cruciaal aspect van API-ontwikkeling. Vereenvoudiging is het beste waar mogelijk.

Een groot debat is enkelvoud versus meervoud zelfstandige naamwoorden. Als u een Twitter-API maakt, heeft u mogelijk de objectgroep als eerste (d.w.z. tweet) en vervolgens het tweede objectitem (d.w.z. tweet-ID).

 $ / tweet / 15032934882934 $ / tweets / 15032934882934 

In dit geval zou ik zeggen dat de enkelvorm er beter uitziet. Dit is met name het geval wanneer slechts één bron wordt geretourneerd. Maar er is geen gedocumenteerd 100% correct antwoord, dus doe wat het beste past bij uw project.

Stel Return Type in

Een andere overweging is type gegevens retourneren. De meeste webgebruikers verwachten JSON-inhoud, dus dat is waarschijnlijk de beste optie. XML is een andere keuze als u beide wilt aanbieden. JSON is echter het fundamentele API-retourtype bij webontwikkelaars.

Er is veel meer in de ontwikkeling van API's, dus ik raad aan eerst met API's te spelen. Op deze manier kunt u zien hoe andere ontwikkelaars hun API's bouwen en hopelijk zult u bekend raken met de typische vereisten.

Als je net begint, overweeg dan om deze dev-tutorials te skimmen:

• REST API zelfstudie-site
• Een eenvoudige REST-API schrijven
• Een RESTful Web Service bouwen

Verdere bronnen

De beste manier om de ontwikkeling van webapp te leren, is door te oefenen. Toegegeven theorie is altijd de moeite van het bestuderen waard, omdat het je in staat stelt om met ontwikkelaars te converseren en te begrijpen hoe de dingen werken.

Maar een goede plek om met API-ontwikkeling te beginnen is verbinding maken met andere API's eerste. Leer de basisprincipes van client-side verbindingen, en vanaf daar kun je doorgaan naar server-side API-ontwikkeling door vanuit het niets je eigen API te maken.

Als dat je doel is, overweeg dan de volgende bronnen om je te helpen tijdens je reis.

Boeken

• REST API Design Rulebook
• RESTful Web API's
• RESTful Web Services Cookbook
• Ongestoord REST: een gids voor het ontwerpen van de perfecte API

artikelen

• Een beginnershandleiding voor HTTP en REST
• Een RESTful API maken
• RESTful Resource Naming Guide
• Een REST API maken met behulp van de MEAN-stack