Video: E conomic integration 2024
Amazon Web Services (AWS), der oprindeligt blev lanceret med SOAP-understøttelse for interaktioner med dets API, men den er stadigt udskrevet for med andre ord) dens SOAP-grænseflade til fordel for REST. Den bedste anbefaling til enhver brug af AWS API er, at du fokuserer på at bruge REST.
På den måde vil du ikke ende med programmer, der engang holder op med at arbejde - længe efter at du har glemt detaljerne i interaktionsmekanismerne. Erfaringen med den ubehagelige opgave at skulle gå tilbage til et system og forsøge at rekonstruere dine handlinger fra måneder eller år tidligere er en uheldig.
Der er ingen mening i fristende skæbne med AWS. Hvis du vil interagere med AWS API, skal du bruge REST, som er Amazons langsigtede retning.
Den ældre tilgang, SOAP (kort for Simple Object Access Protocol), havde bred branchestøtte, komplet med et omfattende sæt standarder. Disse standarder var for omfattende, desværre. De mennesker, der designer SOAP, gør det meget fleksibelt - det kan kommunikere på tværs af internettet, e-mail og private netværk. For at sikre sikkerhed og håndterbarhed blev der også defineret en række understøttende standarder, der integrerer med SOAP.
SOAP er baseret på en dokumentkodningsstandard kendt som Extensible Markup Language (XML, for kort), og SOAP-tjenesten er defineret på en sådan måde, at brugerne derefter kan udnytte XML uanset hvad det underliggende kommunikationsnetværk er. For at dette system skal virke, skal dataene, der overføres af SOAP (almindeligvis benævnt nyttelast ), også være i XML-format.
Bemærk et mønster her? Skubbet til at være omfattende og fleksibelt (eller for at være alle ting for alle mennesker) plus XML-nyttelastkravet indebar, at SOAP endte med at være ret kompleks, hvilket gør det meget arbejde at bruge korrekt. Som du kunne gætte, fandt mange IT-folk SOAP skræmmende og derfor modstandsdygtige med at bruge det.
For en årtier siden definerede en ph.d.-studerende en anden webservice-tilgang som en del af hans afhandling: REST, eller repræsentativ statsoverførsel. REST, som er langt mindre omfattende end SOAP, stræber efter at løse færre problemer. Det omhandler ikke nogle aspekter af SOAP, der syntes vigtig, men det gjorde det efterhånden mere komplekst at bruge - f.eks. Sikkerhed.
Det vigtigste aspekt ved REST er, at det er designet til at integrere med standardwebprotokoller, så REST-tjenester kan kaldes med standardweb-verb og webadresser. For eksempel ser et gyldigt REST-opkald sådan ud:
// søgning.examplecompany. dk / CompanyDirectory / EmployeeInfo? empname = BernardGolden
Det er alt, hvad der kræves for at stille en forespørgsel til eksempelvirksomhedens REST-tjeneste for at se personoplysninger. HTTP-verbet, der følger med denne anmodning, er GET, og beder om, at oplysninger returneres. For at slette oplysninger bruger du verbet DELETE. For at indsætte oplysninger bruger du verbet POST. For at opdatere oplysninger bruger du verbet PUT.
For POST- og PUT-aktionerne suppleres yderligere oplysninger med empname og adskilles med en ampersand (&) for at angive et andet argument, der skal bruges af tjenesten.
REST pålægger ikke nogen specielle formateringskrav på servicebelastningen; I denne henseende adskiller det sig fra SOAP, som kræver XML. For enkle interaktioner er en streng bytes alt hvad du behøver for nyttelastet; for mere komplekse interaktioner (siger ud over at returnere dine medarbejderoplysninger, du ønsker at stille en anmodning om medarbejderinformationen for alle medarbejdere, hvis navne starter med G), anvendes kodningskonventionen JSON. (JSON, hvis du er nysgerrig, står for Javascript-objektnotation.)
Som du måske forventer, gjorde RESTs enklere brugsmodel, dens tilpasning til standardwebprotokoller og verb og den mindre restriktive nyttelastformatering det med udviklere som et hus i brand.
