Video: Getting Started with AWS | Amazon Web Services BASICS 2024
Amazon Web Services (AWS) opprinnelig lansert med SOAP-støtte for samhandling med API-en, men den har stadig avskrevet (redusert støtten for med andre ord) dets SOAP-grensesnitt til fordel for REST. Den beste anbefalingen for bruk av AWS API er at du fokuserer på å bruke REST.
På den måten vil du ikke ende opp med programmer som engang slutter å fungere - lenge etter at du har glemt detaljene i samhandlingsmekanismer. Opplevelsen av den ubehagelige oppgaven med å gå tilbake til et system og forsøke å rekonstruere dine handlinger fra måneder eller år tidligere er en uheldig.
Det er ingen mening i fristende skjebne med AWS. Hvis du vil samhandle med AWS API, bruker du REST, som er Amazons langsiktige retning.
Den eldre tilnærmingen, SOAP (kort for Simple Object Access Protocol), hadde omfattende næringsstøtte, komplett med et omfattende sett av standarder. Disse standardene var for omfattende, dessverre. Personene som designer SOAP, gjør det svært fleksibelt - det kan kommunisere på Internett, e-post og private nettverk. For å sikre sikkerhet og håndterbarhet ble det også definert en rekke støttestandarder som integreres med SOAP.
SOAP er basert på en dokumentkodingsstandard kjent som Extensible Markup Language (XML, for kort), og SOAP-tjenesten er definert på en slik måte at brukerne deretter kan utnytte XML uansett hva det underliggende kommunikasjonsnettverket er. For at dette systemet skal fungere, må dataene som overføres av SOAP (vanligvis referert til som nyttelast ) også være i XML-format.
Merk et mønster her? Pushen til å være omfattende og fleksibel (eller for å være alle ting for alle mennesker) pluss XML-nyttelastkravet betydde at SOAP endte opp med å være ganske komplisert, noe som gjør det mye arbeid å bruke riktig. Som du kanskje gjette, fant mange IT-folk SOAP skremmende og dermed motstått å bruke den.
For en tiår siden definerte en doktorand en annen nettetilgang som en del av hans avhandling: REST, eller Representational State Transfer. REST, som er langt mindre omfattende enn SOAP, ønsker å løse færre problemer. Det tar ikke opp noen aspekter av SOAP som virket viktig, men som i etterkant gjorde det mer komplisert å bruke - for eksempel sikkerhet.
Det viktigste aspektet av REST er at den er utviklet for å integrere med standardwebprotokoller, slik at REST-tjenester kan kalles med standard webverker og nettadresser. For eksempel ser et gyldig REST-anrop ut slik:
// søk.examplecompany. com / CompanyDirectory / EmployeeInfo? empname = BernardGolden
Det er alt som trengs for å stille spørsmål til REST-tjenesten til eksempelfirmaet for å se personellinformasjon. HTTP-verbet som følger med denne forespørselen, er GET, og ber om at informasjon skal returneres. For å slette informasjon bruker du verbet DELETE. For å sette inn informasjon, bruker du verbet POST. For å oppdatere informasjon bruker du verbet PUT.
For POST og PUT-handlingene vil tilleggsinformasjon følge mednavn og skilles med en ampersand (&) for å angi et annet argument som skal brukes av tjenesten.
REST krever ingen spesielle formateringskrav på service nyttelastene; I denne forbindelse er det forskjellig fra SOAP, som krever XML. For enkle samspill, er en rekke byter alt du trenger for nyttelastet; for mer komplekse interaksjoner (si, i tillegg til å returnere din medarbeidsinformasjon, vil du legge inn en forespørsel om de ansatteinformasjonen til alle ansatte hvis navn starter med G), er kodekonvensjonen JSON brukt. (JSON, hvis du er nysgjerrig, står for Javascript-objektnotasjon.)
Som du kanskje forventer, gjorde RESTs enklere bruksmodell, dens tilpasning til standardwebprotokoller og verb, og den mindre restriktiv nyttelastformatering gjort det i stand med utviklere som et hus i brann.
