Pilvipohjaiset API-tietomallit eivät ole vain parantaneet pilvikokemusta, vaan myös tarjoaneet kehittäjille ja järjestelmänvalvojille mahdollisuuden integroida työmäärät pilveen kyseisten sovellusliittymien avulla. Useimmille yrityksille sovellusliittymät mahdollistavat tietojen jakamisen useiden paikallisten ja pilvipohjaisten sovellusten välillä. Niillä on myös tärkeä rooli integroimalla alustan työmäärät saumattomammin. Kun pilvipalvelujen käyttö kasvaa edelleen, integraatiopisteille on enemmän kysyntää pilviympäristön sisä- ja ulkopuolella olevien sovellusten välillä. Multicloud-strategian nousu ja tarve parantaa pilvipalveluita ovat lisänneet riippuvuutta pilvi-API-ympäristöstä. Mutta mikä lähestymistapa on parempi ja mitä tukea saat pilviympäristössäsi?
Saippua pähkinänkuoressa
Vanhemmalla lähestymistavalla SOAP (lyhenne sanoista Simple Object Access Protocol) oli alan laajuinen tuki, joka vaihteli tuoteyrityksistä, kuten IBM ja Microsoft, palvelun toteuttajiin. Sen mukana tuli myös kattava mutta monimutkainen standardisarja. SOAP: n suunnitteleva Microsoft-tiimi teki siitä erittäin joustavan - kykenevän kommunikoimaan yksityisten verkkojen, Internetin ja sähköpostin kautta. Sitä tukivat myös useat standardit. SOAP: n alkuperäinen versio oli osa eritelmää, joka sisälsi myös Universal Description, Discovery and Integration (UDDI) - ja Web Services Description Language (WSDL) -kielet.
SOAP tarjoaa lähinnä kirjekuoren verkkopalveluviestien lähettämistä varten. Itse arkkitehtuuri on suunniteltu auttamaan erilaisten ohjelmien välisten toimintojen suorittamisessa. Viestintä ohjelmien välillä tapahtuu yleensä XML-pohjaisten pyyntöjen ja HTTP-pohjaisten vastausten kautta. HTTP on enimmäkseen käytetty yhteyskäytäntö, mutta myös muita protokollia voidaan käyttää.
SOAP-viesti sisältää joitain pakollisia osia, kuten KIRJEKUORI, HEADER, RUUMIja VIKA.KIRJEKUORI object määrittää XML-viestipyynnön alun ja lopun, HEADER sisältää kaikki palvelimen käsittelemät otsikkoelementit ja RUNKO sisältää jäljellä olevan XML-objektin, joka muodostaa pyynnön. VIKA objektia käytetään mitä tahansa virheiden käsittelyä.
LEVÄTÄ
REST (Representational State Transfer) -palvelua kutsutaan yleensä arkkitehtuurityyliksi eikä protokollaksi, jota käytetään verkkopalvelujen rakentamiseen. REST-arkkitehtuuri mahdollistaa kahden ohjelmiston välisen viestinnän, jolloin yksi ohjelma voi pyytää ja käsitellä resursseja toiselta. Kohdeohjelman resurssien käyttämistä koskeva REST-pyyntö käyttää HTTP-verbejä: SAADA, LÄHETTÄÄ, LAITTAAja POISTAA. Nämä pyynnöt voivat käyttää tietomuotoa, mukaan lukien XML, HTML ja JSON. JSON on edullisin, koska se on yhteensopivin ja helppokäyttöisin. useimmat REST-sovellusliittymät perustuvat URI-tunnuksiin (Uniform Resource Identifier) ja ovat erityisiä HTTP-protokollalle.
REST on kehittäjäystävällinen, koska sen yksinkertaisempi tyyli helpottaa käyttöönottoa ja käyttöä kuin SOAP. REST on vähemmän yksityiskohtainen, ja pienempi määrä dataa lähetetään, kun kommunikoidaan kahden päätepisteen välillä.
Miksi SOAP tai REST?
Vaikka SOAP on kuin kirjekuoren käyttö, joka sisältää paljon prosessointitietoja sen sisällä, REST voidaan pitää postikorttina, jolla on URI kohdeosoitteena, kevyt ja välimuistissa. REST on tietopohjainen ja sitä käytetään ensisijaisesti resurssin (URI) käyttämiseen tietyille tiedoille; SOAP on toimintopohjainen protokolla. REST tarjoaa joustavuuden tietomuodon (pelkkäteksti, HTML, XML tai JSON) valinnassa, kun taas SOAP käyttää vain XML: ää.
SOAP soveltuu hyvin sovelluksiin, joissa tarvitset korkeamman suojaustason. SOAP sisältää yritystason suojausominaisuudet, joita WS-Security tukee, sekä SSL-tuki. Jos haluat kehittää mobiilipankkiratkaisua, SOAP-sovellusliittymät olisivat todennäköisesti ensimmäinen huomio turvallisuusvaatimuksissa. SOAP tarjoaa myös uudelleenlogiikan taattuun menestykseen ja luotettavaan viestintään. REST käyttää HTTP: tä ja voi korjata viestintäongelmat vain yrittämällä uudelleen, mutta uudelleenyrityslogiikkaa ei ole sisäänrakennettu REST: n kanssa. SOAP tarjoaa sisäänrakennetun uudelleenlogiikan.
Mitä muutoksia pilvipohjaisessa ympäristössä?
Kehittäjän näkökulmasta mikään ei todellakaan muutu valinnassa REST- tai SOAP-vaihtoehtojen välillä, mutta palvelun suunnittelu pilvipohjaisessa ympäristössä tuo alustan näkökulman huomioon. Palvelujen saatavuudella ja vasteajalla on ratkaiseva rooli yrityspalvelujen ja pilvipalvelujen suunnittelussa. Suojauksen näkökulmasta WS-Security (Web Service Security) -protokollaa, joka tarjoaa päästä päähän -tason suojauksen SOAP-viestejä käyttämällä, käytetään laajalti pilvipalvelussa useimpien pilvipalveluihin liittyvien verkkopalvelujen turvallisuuden suojaamiseksi. Mutta WS-Security käyttää SAOP-otsikkoelementtejä turvallisuuteen liittyvien tietojen siirtämiseen. SOAP-viesti on XML-tyyppinen muoto ja yleensä kooltaan paljon suurempi kuin varsinainen sanoma binaarimuodossa. Tämä lisää aikaa ja käsittelyä tiedonsiirtoon ja tietojen käsittelyyn. Tämä voi olla väittely REST: n ja SOAP: n valinnassa, mutta siirtyminen SOAP: sta REST: iin tapahtuu riippumatta alustasta, jota sovelluksesi käyttää.
Vuoden 2016 loppupuolella Microsoft Azure lisäsi SOAP-läpivientituen Azure API Managementiin, joka auttaa kehittäjiä luomaan välityspalvelimen SOAP-sovellusliittymilleen samalla tavalla kuin he luovat välityspalvelimen REST / HTTP-sovellusliittymille. SOAP-läpivientitukea käyttämällä voit tuoda WSDL-asiakirjoja ja luoda uuden API-välityspalvelimen; prosessi tarkastelee kaikkia asiakirjan SOAP-toimintoja ja luo ne tehokkaasti API-päätepisteisiin. Tulevassa versiossa saatamme nähdä ominaisuuden, jota on pyydetty luomaan REST-käyttöliittymä SOAP-käyttöjärjestelmää käyttämällä.
AWS-maailmassa suurin osa AWS-sovellusliittymistä on käytettävissä vain REST-yhteyden kautta ja niillä on rajoitettu tuki SOAP: lle. EC2-resursseja on saatavana REST- tai Query-sovellusliittymän kautta, kun taas EC2: n SOAP-sovellusliittymä on ollut vanhentunut vuoden 2015 lopusta lähtien. Palvelut, kuten Amazon S3 ja RDS, tukevat myös REST: ää, kun taas SOAP: ta tuetaan vain HTTPS: n kautta; HTTP: n SOAP on vanhentunut. Amazon SQS ei enää tue SOAPia. Vaikka REST näyttää johtavan AWS-sovellusliittymiä, Amazon API -yhdyskäytävä integroituu AWS-ekosysteemiin ja tarjoaa tukea RESTful-sovellusliittymän luomiseen, hallintaan ja käyttöönottoon taustan HTTP / HTTPS-päätepisteiden, AWS Lambda -toimintojen ja / tai muiden AWS-palveluiden paljastamiseksi. API-yhdyskäytävä auttaa myös altistuneiden API-menetelmien kutsumista käyttöliittymän HTTP-päätepisteiden kautta.
Yhä useampi tuki nojaa RESTful-sovellusliittymiin. Sen yksinkertaisuus verbimäisten toimintojen kanssa tekee siitä kehittäjäystävällisen. Se on yhteensopiva useimpien formaattien kanssa ja sitä on helppo käyttää. Myöskään SOAP: lla ei ole auringonlaskua, mutta REST tulee varmasti olemaan suosittu kehittäjäyhteisön keskuudessa.
