it-swarm-eu.dev

Výhody a nevýhody RESTful architektury

Nejběžnější diskuse, kterou jsem viděl o výhodách a nevýhodách REST má tendenci tuto diskusi orámovat ve vztahu k SOAP. Nemám také žádné zkušenosti. V současné době čelím rozhodnutí, které můj nedostatek zkušeností je pro mě obtížné vyhodnotit. Začínám vyvíjet aplikaci, která má několik komponent - primárně administrativní aspekt, který umožňuje majiteli spravovat několik webů - a veřejné uživatelské rozhraní, které uživateli umožňuje interakci s uchovávanými daty na hostiteli. Musím zhodnotit důsledky umožnění hostování druhé části kdekoli a komunikaci s prvkem prostřednictvím architektury RESTful - nebo vyžadovat, aby obě komponenty byly umístěny na stejném hostiteli. Jaké jsou klíčové důsledky rozvoje architektury RESTful, zejména s ohledem na jeho kapacitu v následujících oblastech:

1: Zabezpečení 2: Výkon 3: Složitost rozhraní

EDIT: Při pohledu na některé odpovědi na tuto otázku - měl bych to objasnit. Nehledám srovnání s SOAP - spíše přehled REST aplikací vs aplikací, kde všechny komponenty sídlí na jednom hostiteli) (děkuji za ty odpovědi) ačkoli!)

20
sunwukung

Vzhledem k těmto oblastem mohu poskytnout hrubý přehled, ale nemohu pro vás vyvodit vaše závěry. Existují dvě hlavní oblasti, kde se oba protokoly liší:

  • Formát zprávy
  • Vyhledání služby

Formát zprávy je nejsnadnější pochopit. Balení SOAP pro požadavky i odpovědi má poměrně velkou váhu. Existuje obálka SOAP, která obsahuje záhlaví i část těla. Záhlaví může být použito několika filtry v řetězci požadavků k provedení nějaké identifikace, autorizace atd. XML je však velmi nákladné analyzovat, což přináší určitou penalizaci škálovatelnosti vašeho systému. Jak moc závisí na vrstvě zpracování SOAP ve vašem zásobníku.

Zjištění služby je místo, kde pravděpodobně budete mít největší spor. REST ze své podstaty poskytuje předvídatelné koncové body a obsah požadavku je jednoduchý HTTP požadavek. Výhoda spočívá v tom, že neexistují žádné další režijní náklady a koncoví uživatelé mohou do značné míry hádat, jak dělat to, co potřebují, jakmile pochopí strukturu adres URL vašeho webu. Naivní lidé, kteří si uvědomují bezpečnost, to pochopitelně pochopí jako slabost. Nakonec musíte pomocí SOAP zkonzumovat WSDL, abyste věděli, jaké jsou koncové body. Samozřejmě, s SOAP jste dostali celý formát zprávy, abyste mohli provádět cílenější útoky.

Rozdělené podle kategorií, které jste dali:

Zabezpečení

Ani jeden není ze své podstaty bezpečnější než ten druhý. Používejte dobré zásady zabezpečení:

  • Šifrovat komunikaci
  • Před zpracováním ověřte a ověřte uživatele
  • Dobré návyky kódování, aby se zabránilo přímým útokům
  • A to je užší seznam.

Pamatujte na nejasnost! = Bezpečnost.

Výkon

Jak surový výkon, tak škálovatelnost půjde na REST kvůli požadavku, který následuje po jednoduchých protokolech HTTP. Většina stohů SOAP používá parsování SAX (parsing na základě událostí), což výrazně zlepšuje škálovatelnost stohů SOAP, ale je zde měřitelný dopad na režii. SOAP má normální režii zpracování HTTP kromě režie XML analýzy. REST má pouze režii zpracování HTTP.

Složitost

Z pohledu systému vyhrává REST. Je zde méně pohyblivých součástí, štíhlejší řetěz žádostí atd. To znamená, že je snazší spolehlivě vyrobit.

Z pohledu programátora může SOAP zvítězit, pokud IDE nebo rámec, který používáte, poskytuje dobrou podporu. V podstatě, s REST je na vás, abyste provedli předzpracování (autentizace/autorizace/atd.), Zatímco s SOAP většinu toho lze dosáhnout pomocí zpracovatelského řetězce, který lze zapojit.

Moje preference

S požadavky HTTP jsem velmi spokojený a vím, jak web funguje. V důsledku toho je pro mě výhodnější přístup REST. Vím však, že někteří z mých klientů jsou s tím nepříjemní. Přečetli si článek v oboru, který odsuzuje zabezpečení REST vs. SOAP atd. Sečteno podtrženo, že ani jeden přístup nezaručuje bezpečnost. Je na vás, abyste se ujistili, že aplikace je tak bezpečná, jak musí být. Je zřejmé, že sociální webová aplikace nevyžaduje (nebo touží) tolik bezpečnosti jako banka nebo vládní systém. Mnoho zásobníků SOAP obsahuje procesory, které můžete připojit, abyste zajistili jistotu zdání bezpečnosti, ale stále je vaší odpovědností je vyhledat a umístit na místo.

13
Berin Loritsch
  1. Zabezpečení: Použijte HTTPS. To platí pro oba.
  2. Výkon: . REST je levnější PROCESOR (méně analýzy, zařazování, rozbalování). Také ukládání do mezipaměti s REST je kousek koláče).
  3. Složitost: REST vyžaduje mnohem méně, pokud jde o nastavení, je to nakonec jen GET/POST. SOAP vyžaduje mnohem více správy pro údržbu (wsdl atd.), Ale je o něco jednodušší, pokud to váš IDE) podporuje.

Myslím, že MÝDLO je příliš nafouklé, když můžete udělat totéž s REST a některým typem obsahu/mime). Rovněž SOAP přináší spoustu režijních nákladů, a to díky své povaze obalů obalů a skutečnosti, že je obecnější a neomezuje se na HTTP. SOAP je lákavé použít, pokud váš IDE podporuje správně a nechcete se učit HTTP. Ale pro mě je REST je mnohem jednodušší použití a mnohem více přátelské k webu.

V dnešní době existují velmi dobrá rozhraní API REST). Pokud jste v Javě, pak je Jax-RS opravdu v pohodě. Pro některé lidi je toto jako porno .

12
Martin Wickman

Myslím si, že největší výhodou REST) je přejít z architektur RPC. REST odhaluje zdroje, nikoli procesy. To vám umožní vytvořit volně vázaný systém, kde změny, vylepšení, dokonce i poruchy jedné části mají omezený (negativní) dopad na jiné části.

Bohužel, častým zneužitím REST) je odhalit vaše vnitřní datové struktury (v nejhorších případech je to CRUD vaší databáze, ugh). Díky tomu je velmi „Správným“ použitím je odhalit objekty na vysoké úrovni, které jsou relevantní pro část systému, se kterým pracujete, a liberálně vrátit kódy chybových stavů při jakékoli nekonzistenci.

Další často přehlíženou částí REST je idempotence většiny sloves.) Nejen GET, ale také PUT a DELETE by měl být přesně stejný výsledek, pokud bude použit jednou nebo vícekrát (jste bez vrácení 404, pokud již bylo odstraněno, nebo „žádná změna“, pokud klient PUTting stejný). To vede k robustním systémům a menší vzájemné závislosti přesných interpretací sémantiky.

8
Javier

Standardy WS- * jsou ve skutečnosti většinou o spuštění RPC přes SOAP/HTTP. Veškeré myšlení, které šlo o CORBA a J2EE, a jejich předchůdci se většinou přesunuli k tomu, aby v XML dělali stejné věci. To znamená věci, jako jsou typová prohlášení a smlouvy o poskytování služeb, výměna metadat, deklarativní zabezpečení atd. Všechny ty skutečné „podnikové“ věci. Je upřímně použitelný i v podniku.

Lidé, kteří vytvářejí internetovou webovou aplikaci, jako jste vy, by s jistotou měli lepší využití RESTful architektury. Téměř jakákoli platforma jej může spotřebovat a dělat tak jednoduše a bez obav, jakou verzi které specifikace používáte a nesčetné množství zvláštních typů konverzních šablon atd.

3
Jeremy

Jedinou velkou výhodou SOAP oproti současným REST implementací je to, že SOAP je jednodušší nástroj - většina RESTful klientů vyžaduje) Abych porozuměl rozhraní a psal klienta nějakého druhu. Pro SOAP jsem na něj poukazoval wsdl.exe a generoval pro mě třídy.

0
Wyatt Barnett