Video: Introduction to Amazon Web Services by Leo Zhadanovsky 2024
Amazon Web Services (AWS) som ursprungligen lanserades med SOAP-stöd för interaktioner med dess API, men det har stadigt försvunnit för med andra ord) dess SOAP-gränssnitt till förmån för REST. Den bästa rekommendationen för användningen av AWS API är att du fokuserar på att använda REST.
På så sätt kommer du inte att sluta med program som någonsin slutar fungera - långt efter att du har glömt detaljerna i interaktionsmekanismerna. Erfarenheten av den obehagliga uppgiften att behöva gå tillbaka till ett system och försöka rekonstruera dina handlingar från månader eller år tidigare är en olycklig.
Det finns ingen mening i frestande öde med AWS. Om du vill interagera med AWS API använder du REST, som är Amazons långsiktiga riktning.
Det äldre tillvägagångssättet, SOAP (kort för Simple Object Access Protocol), hade omfattande branschsupport, komplett med en omfattande uppsättning standarder. Dessa standarder var för omfattande, tyvärr. De personer som utformar SOAP gör det mycket flexibelt - det kan kommunicera via webben, e-post och privata nätverk. För att säkerställa säkerhet och hanterbarhet definierades också ett antal stödjande standarder som integrerades med SOAP.
SOAP är baserat på en dokumentkodningsstandard som kallas Extensible Markup Language (XML, för kort), och SOAP-tjänsten är definierad så att användare sedan kan utnyttja XML oavsett vad det underliggande kommunikationsnätet är. För att detta system ska kunna fungera måste dock data som överförts av SOAP (vanligen kallad nyttolast ) vara i XML-format.
Lägg märke till ett mönster här? Skyddet att vara omfattande och flexibelt (eller att vara allt för alla) plus XML-nyttolånets krav innebar att SOAP slutade vara ganska komplex, vilket gör det mycket arbete att använda korrekt. Som du kan gissa, fann många IT-personer SOAP skrämmande och följaktligen motsatte sig att använda den.
För en decennium sedan definierade en doktorand en annan webbtjänst som en del av hans avhandling: REST eller Representational State Transfer. REST, som är långt mindre omfattande än SOAP, strävar efter att lösa färre problem. Det tar inte upp några aspekter av SOAP som verkade vara viktiga, men som i efterhand gjorde det mer komplext att använda - till exempel säkerhet.
Den viktigaste aspekten av REST är att den är utformad att integrera med standardwebprotokoll så att REST-tjänster kan kallas med standardwebverken och webbadresser. Till exempel ser ett giltigt REST-samtal ut så här:
// search.examplecompany. com / CompanyDirectory / EmployeeInfo? empname = BernardGolden
Det är allt som krävs för att göra en fråga till REM-tjänsten i exempelbolaget för att se personalinformation. HTTP-verbet som följer med denna förfrågan är GET och begär att information ska returneras. För att radera information använder du verbet DELETE. För att infoga information använder du verbet POST. För att uppdatera information använder du verket PUT.
För POST- och PUT-åtgärderna kommer ytterligare information att följa med namnet och separeras med en ampersand (&) för att ange ett annat argument som ska användas av tjänsten.
REST ställer inga särskilda formateringskrav på service nyttolast I detta avseende skiljer sig det från SOAP, vilket kräver XML. För enkla interaktioner är en sträng bytes allt du behöver för nyttolasten. för mer komplexa interaktioner (säg att du, förutom att returnera din personalinformation, vill lägga fram en begäran om anställdas information för alla anställda vars namn börjar med G) används kodningsavtalet JSON. (JSON, om du är nyfiken, står för Javascript-objektnotation.)
Som du kanske förväntar sig gjorde RESTs enklare användarmodell, dess anpassning till standardwebprotokoll och verb och den mindre restriktiva nyttolastformatet det med utvecklare som ett hus i brand.
