Video: Restful Web Service Tip 7 - Have Great Documentation 2024
Amazon Web Services (AWS) is oorspronkelijk gelanceerd met SOAP-ondersteuning voor interacties met zijn API, maar het is gestaag verouderd (verminderde de ondersteuning voor, met andere woorden) zijn SOAP-interface in het voordeel van REST. De beste aanbeveling voor het gebruik van de AWS API is dat u zich concentreert op het gebruik van REST.
Op die manier kom je niet uit bij programma's die ooit stoppen met werken - lang nadat je de details van de interactiemechanismen bent vergeten. De ervaring van de onplezierige taak om terug te gaan naar een systeem en proberen je acties van maanden of jaren eerder te reconstrueren is een ongelukkige.
Het heeft geen zin het lot aan te vallen met AWS - als je wilt communiceren met de AWS API, gebruik dan REST, wat Amazon's lange termijn richting is.
De oudere aanpak, SOAP (afkorting van Simple Object Access Protocol), had brede ondersteuning voor de industrie, compleet met een uitgebreide reeks standaarden. Die normen waren helaas te uitgebreid. De mensen die SOAP ontwerpen, stellen het in als extreem flexibel: het kan communiceren via internet, e-mail en privénetwerken. Om de veiligheid en beheersbaarheid te waarborgen, werden ook een aantal ondersteunende normen gedefinieerd die integreren met SOAP.
SOAP is gebaseerd op een standaard voor documentcodering die bekend staat als Extensible Markup Language (XML, kortweg) en de SOAP-service is zodanig gedefinieerd dat gebruikers XML kunnen gebruiken ongeacht wat het onderliggende communicatienetwerk is. Om ervoor te zorgen dat dit systeem werkt, moeten de gegevens die worden overgedragen door SOAP (gewoonlijk aangeduid als payload ) ook in XML-indeling zijn.
Zie je hier een patroon? De push om allesomvattend en flexibel te zijn (of om alle dingen voor alle mensen te zijn) plus de XML-payload-eis betekende dat SOAP uiteindelijk behoorlijk ingewikkeld werd, waardoor het een hoop werk was om correct te gebruiken. Zoals je zou kunnen raden, vonden veel IT-mensen SOAP angstaanjagend en verzetten ze zich er daarom tegen.
Ongeveer een decennium geleden definieerde een doctoraalstudent een andere webdienstenaanpak als onderdeel van zijn proefschrift: REST, of Representational State Transfer. REST, dat veel minder uitgebreid is dan SOAP, heeft de ambitie om minder problemen op te lossen. Het gaat niet in op sommige aspecten van SOAP die belangrijk leken, maar die het achteraf gezien ingewikkelder maakte om te gebruiken - bijvoorbeeld beveiliging.
Het belangrijkste aspect van REST is dat het is ontworpen om te worden geïntegreerd met standaard webprotocollen, zodat REST-services kunnen worden aangeroepen met standaard webwerkwoorden en URL's. Een geldige REST-aanroep ziet er bijvoorbeeld als volgt uit:
// search.examplecompany. com / CompanyDirectory / EmployeeInfo? empname = BernardGolden
Dat is alles wat nodig is om een vraag te stellen aan de REST-service van examplecompany om personeelsinformatie te bekijken. Het HTTP-werkwoord dat bij dit verzoek hoort, is GET en vraagt om teruggave van informatie. Om informatie te verwijderen, gebruikt u het werkwoord DELETE. Om informatie in te voegen, gebruikt u het werkwoord POST. Om informatie bij te werken, gebruik je het werkwoord PUT.
Voor de POST- en PUT-acties zou extra informatie de empname vergezellen en worden gescheiden door een ampersand (&) om een ander argument aan te geven dat door de service moet worden gebruikt.
REST legt geen specifieke opmaakvereisten op voor de serviceprachtlasten; in dit opzicht verschilt het van SOAP, wat XML vereist. Voor eenvoudige interacties is een reeks bytes alles wat u nodig hebt voor de payload; voor complexere interacties (bijvoorbeeld, naast het retourneren van uw werknemersinformatie, wilt u een verzoek indienen voor de werknemersinformatie van alle medewerkers waarvan de namen beginnen met G), wordt de coderingsconventie JSON gebruikt. (JSON, als je nieuwsgierig bent, staat voor Javascript Object Notation.)
Zoals je zou verwachten, raakte het eenvoudigere gebruiksmodel van REST, de afstemming op standaard webprotocollen en werkwoorden en de minder beperkende indeling van de nuttige lading doorontwikkeld. zoals een huis in brand.
