Programování

REST nebo SOAP v prostředí nativního cloudu

Datové modely API založené na cloudu nejenže vylepšily cloudový zážitek, ale také poskytly vývojářům a správcům způsob, jak integrovat pracovní zátěže do cloudu pomocí těchto API. Pro většinu podniků umožňují rozhraní API sdílet informace v různých místních a cloudových aplikacích. Hrají také důležitou roli pro bezproblémovou integraci pracovních zátěží platformy. Vzhledem k tomu, že adopce cloudu stále roste, existuje větší poptávka po integračních bodech mezi aplikacemi uvnitř i vně cloudového prostředí. Rise of multicloud strategy along with need for enhancing in cross cloud capabilities have increased the dependency on cloud API environment. Ale který přístup je lepší a jakou podporu ve svém cloudovém prostředí získáte?

SOAP v kostce

SOAP (zkratka pro Simple Object Access Protocol), starší přístup, měl celosvětovou podporu od produktových společností jako IBM a Microsoft až po implementátory služeb. Přišlo také s komplexní, ale složitou sadou standardů. Tým společnosti Microsoft, který vytvořil SOAP, se stal extrémně flexibilním - aby mohl komunikovat přes soukromé sítě, přes internet a e-maily. Bylo podporováno také několika standardy. Počáteční verze protokolu SOAP byla součástí specifikace, která obsahovala také Universal Description, Discovery a Integration (UDDI) a Web Services Description Language (WSDL).

SOAP v podstatě poskytuje obálku pro odesílání zpráv webových služeb. Samotná architektura je navržena tak, aby napomáhala výkonu různých operací mezi softwarovými programy. Komunikace mezi programy se obvykle děje prostřednictvím požadavků založených na XML a odpovědí založených na HTTP. HTTP je většinou používaný komunikační protokol, ale lze použít i jiné protokoly.

Zpráva SOAP obsahuje některé povinné části, například OBÁLKA, Záhlaví, TĚLO, a CHYBA. TheOBÁLKA objekt definuje začátek a konec požadavku na zprávu XML, Záhlaví obsahuje všechny prvky záhlaví, které mají být zpracovány serverem, a TĚLO obsahuje zbývající objekt XML, který tvoří požadavek. CHYBA objekt se používá jakékoli zpracování chyb.

ZBYTEK

REST (Reprezentativní přenos stavu) se obvykle označuje spíše jako architektonický styl než jako protokol, který se používá k vytváření webových služeb. Architektura REST umožňuje komunikaci mezi dvěma softwarovými programy, přičemž jeden program může vyžadovat a manipulovat se zdroji od druhého. Požadavek REST pro přístup k prostředkům v cílovém programu používá slovesa HTTP: DOSTAT, POŠTA, DÁT, a VYMAZAT. Tyto požadavky mohou používat datový formát včetně XML, HTML a JSON. JSON je nejvýhodnější, protože je nejkompatibilnější a snadno použitelný. většina rozhraní REST API je založena na identifikátorech URI (Uniform Resource Identifier) ​​a je specifická pro protokol HTTP.

REST je vhodný pro vývojáře, protože jeho jednodušší styl usnadňuje implementaci a použití než SOAP. REST je méně podrobný a při komunikaci mezi dvěma koncovými body se odesílá menší objem dat.

Proč SOAP nebo REST?

Zatímco SOAP je jako používat obálku, která obsahuje spoustu informací o zpracování, REST lze považovat za pohlednici, která má jako cílovou adresu URI, je lehká a lze ji uložit do mezipaměti. REST je založen na datech a primárně se používá pro přístup k prostředku (URI) pro určitá data; SOAP je protokol založený na funkcích. REST poskytuje flexibilitu při výběru datového formátu (prostý text, HTML, XML nebo JSON), zatímco SOAP používá pouze XML.

SOAP je vhodný pro aplikace, kde potřebujete vyšší úroveň zabezpečení. SOAP přichází s funkcemi zabezpečení na podnikové úrovni podporovanými WS-Security, spolu s podporou SSL. Pokud chcete vyvinout řešení mobilního bankovnictví, SOAP API by pravděpodobně byla první úvaha o bezpečnostních požadavcích. SOAP také poskytuje logiku opakování pro zaručený úspěch a spolehlivou komunikaci. REST používá HTTP a může řešit selhání komunikace pouze opakováním pokusu, ale logika opakování není součástí REST. SOAP poskytuje integrovanou logiku opakování.

Jaké změny v prostředí nativního cloudu?

Z pohledu vývojáře se při výběru mezi REST nebo SOAP ve skutečnosti nic nezmění, ale návrh vaší služby v prostředí nativního cloudu přináší perspektivu platformy do úvah. Dostupnost služby a doba odezvy hraje při navrhování podnikových služeb a nativních cloudových aplikací zásadní roli. Z bezpečnostního hlediska je v cloud computingu široce používán protokol WS-Security (Web Service Security), který poskytuje end-to-end zabezpečení na úrovni zpráv pomocí zpráv SOAP, aby ochránil zabezpečení většiny webových služeb souvisejících s cloud computingem. Ale WS-Security používá k přenosu informací souvisejících se zabezpečením prvky záhlaví SAOP. Zpráva SOAP má formát typu XML a má obvykle mnohem větší velikost než skutečná zpráva v binárním formátu. To zvyšuje čas a zpracování pro komunikaci a zpracování dat. To může být argumentem debaty pro výběr REST versus SOAP, ale dochází k posunu od SOAP k REST bez ohledu na platformu, na které bude vaše aplikace spuštěna.

Pozdní v roce 2016 Microsoft Azure přidal podporu průchodu SOAP do Azure API Management, která pomáhá vývojářům vytvořit proxy pro jejich SOAP API stejným způsobem, jakým vytvářejí proxy pro REST / HTTP API. Pomocí podpory průchodu SOAP můžete importovat dokumenty WSDL a vytvořit nový proxy API; proces sleduje všechny akce SOAP v dokumentu a efektivně je vytváří do koncových bodů API. V budoucí verzi se může zobrazit funkce požadovaná k vytvoření front-endu REST pomocí back-endu SOAP.

Ve světě AWS je většina API AWS přístupná pouze prostřednictvím REST a má omezenou podporu pro SOAP. Prostředky EC2 jsou k dispozici prostřednictvím rozhraní REST nebo Query API, zatímco rozhraní SOAP API pro EC2 je od konce roku 2015 zastaralé. Služby jako Amazon S3 a RDS také podporují REST, zatímco protokol SOAP je podporován pouze prostřednictvím protokolu HTTPS; SOAP pro HTTP je zastaralý. Amazon SQS již nepodporuje SOAP. Zatímco se zdá, že REST vede API AWS, brána Amazon API Gateway se integruje s ekosystémem AWS a poskytuje podporu při vytváření, správě a nasazování rozhraní RESTful API k vystavení koncových bodů HTTP / HTTPS typu back-end, funkcí AWS Lambda a / nebo jiných služeb AWS. API Gateway také pomáhá Vyvolání exponovaných metod API prostřednictvím koncových bodů HTTP front-end.

Stále více podpory se opírá o RESTful API. Díky jeho jednoduchosti s operacemi podobnými slovesu je vývojářsky přívětivý. Je kompatibilní s většinou formátů a snadno se používá. Pro SOAP také neexistuje žádný západ slunce, ale REST bude určitě populární mezi komunitou vývojářů.