Plusy i minusy architektury RESTful [zamknięte]

Najczęstsza dyskusja, jaką widziałem na temat zalet i wad REST, ma tendencję do ujęcia tej dyskusji w stosunku do SOAP. W obu nie mam doświadczenia. Obecnie mam do czynienia z decyzją, która utrudnia mi ocenę. Zaczynam opracowywać aplikację, która ma kilka składników - przede wszystkim aspekt administracyjny, który pozwala właścicielowi administrować kilkoma witrynami - oraz publiczny interfejs użytkownika, który umożliwia interakcję z danymi przechowywanymi na hoście. Muszę ocenić konsekwencje umożliwienia hostowania drugiej części w dowolnym miejscu i komunikowania się z pierwszą za pośrednictwem architektury RESTful - lub wymagając, aby oba komponenty znajdowały się na tym samym hoście. Jakie są kluczowe implikacje rozwoju architektury RESTful, szczególnie w odniesieniu do jej możliwości w następujących obszarach:

1: Bezpieczeństwo 2: Wydajność 3: Złożoność interfejsu

EDYCJA: Patrząc na niektóre odpowiedzi na to pytanie - powinienem wyjaśnić. Nie szukam porównania z SOAP - raczej przegląd aplikacji REST w porównaniu z aplikacjami, w których wszystkie komponenty znajdują się na jednym hoście. (dzięki za te odpowiedzi!)

Biorąc pod uwagę te obszary, mogę podać ogólny zarys, ale nie mogę wyciągnąć dla ciebie wniosków. Istnieją dwa główne obszary, w których oba protokoły różnią się:

• Format wiadomości
• Odkrycie usługi

Format wiadomości jest najłatwiejszy do zrozumienia. Opakowanie SOAP zarówno dla żądań, jak i odpowiedzi ma dość dużą wagę. Istnieje obwiednia SOAP, która zawiera zarówno nagłówek, jak i sekcję treści. Nagłówek może być wykorzystywany przez kilka filtrów w łańcuchu żądań w celu wykonania pewnego rodzaju identyfikacji, autoryzacji itp. Jednak XML jest parsowany, co wiąże się z pewną karą dla skalowalności twojego systemu. To, ile zależy od warstwy przetwarzania SOAP w stosie.

Odkrycie usług to miejsce, w którym prawdopodobnie będziesz miał najwięcej sporów. REST ze swej natury zapewnia przewidywalne punkty końcowe, a treść żądania jest prostym żądaniem HTTP. Zaletą jest to, że nie ma dodatkowych kosztów ogólnych, a użytkownicy końcowi mogą zgadnąć, jak zrobić to, czego potrzebują, gdy zrozumieją strukturę adresu URL witryny. Oczywiście naiwni świadomi bezpieczeństwa ludzie postrzegają to jako słabość. W końcu z SOAP musisz zużyć WSDL, aby wiedzieć, jakie są punkty końcowe. Oczywiście dzięki SOAP otrzymałeś cały format wiadomości, dzięki czemu możesz przeprowadzać bardziej ukierunkowane ataki.

Podział według podanych kategorii:

Bezpieczeństwo

Żadna z nich nie jest z natury bezpieczniejsza niż druga. Stosuj dobre zasady bezpieczeństwa:

• Szyfruj komunikację
• Upewnij się, że uwierzytelniasz i autoryzujesz użytkowników przed przetwarzaniem
• Dobre nawyki kodowania, aby uniknąć bezpośrednich ataków
• A to tylko krótka lista.

Pamiętaj o niejasności! = Bezpieczeństwo.

Występ

Zarówno surowa wydajność, jak i skalowalność przejdzie do REST z powodu żądania zgodnego z prostymi protokołami HTTP. Większość stosów SOAP wykorzystuje parsowanie SAX (parsowanie oparte na zdarzeniach), co znacznie poprawia skalowalność stosów SOAP, ale ma to wymierny wpływ na koszty ogólne. SOAP ma normalny narzut przetwarzania HTTP oprócz narzutu parsowania XML. REST po prostu ma narzut przetwarzania HTTP.

Złożoność

Z perspektywy systemu wygrywa REST. Jest mniej ruchomych części, krótszy łańcuch zapytań itp. Oznacza to, że łatwiej jest zapewnić niezawodność.

Z perspektywy programisty SOAP może wygrać, jeśli używane środowisko IDE lub framework zapewnia dobre wsparcie dla niego. Zasadniczo z REST spoczywa na tobie obowiązek wykonywania czynności wstępnego przetwarzania (uwierzytelnianie / autoryzacja / itp.), Podczas gdy przy SOAP wiele z nich można osiągnąć za pomocą podłączanego łańcucha przetwarzania.

Moja preferencja

Bardzo dobrze czuję się z żądaniami HTTP i wiem, jak działa sieć. W rezultacie podejście REST jest dla mnie bardziej preferowane. Wiem jednak, że niektórym z moich klientów nie podoba się to. Przeczytali artykuł branżowy potępiający bezpieczeństwo REST vs. SOAP itp. Najważniejsze jest to, że żadne podejście nie gwarantuje bezpieczeństwa. Dopilnuj, aby aplikacja była tak bezpieczna, jak to konieczne. Oczywiście społeczna aplikacja internetowa nie wymaga (ani nie pragnie) takiego bezpieczeństwa, jak system bankowy lub rządowy. Wiele stosów SOAP zawiera procesory, które można podłączyć, aby zapewnić pozory bezpieczeństwa, ale nadal Twoim obowiązkiem jest ich przeszukać i zainstalować.

1. Bezpieczeństwo: użyj HTTPS. Dotyczy to obu.
2. Wydajność: . REST kosztuje mniej procesora (mniej parsowania, zestawiania, rozpakowywania). Również buforowanie przy użyciu REST to bułka z masłem.
3. Złożoność: REST wymaga znacznie mniej pod względem konfiguracji, w końcu to tylko GET / POST. Protokół SOAP wymaga znacznie więcej administracji (WSDL itp.), Ale jest nieco łatwiejszy, jeśli IDE go obsługuje.

Myślę, że SOAP jest zbyt rozdęty, kiedy możesz zrobić to samo z REST i niektórymi typami treści / mime. Ponadto SOAP przynosi wiele narzutów, ze względu na swój charakter owijania opakowań i fakt, że jest bardziej ogólny i nie ogranicza się do HTTP. SOAP kusi do użycia, jeśli IDE obsługuje go poprawnie i nie chcesz uczyć się HTTP. Ale dla mnie REST jest znacznie łatwiejszy w użyciu i bardziej przyjazny dla sieci.

Obecnie istnieją bardzo dobre interfejsy API REST do użycia. Jeśli lubisz Javę, Jax-RS jest naprawdę fajny. Dla niektórych ludzi, to jest jak porno.

Myślę, że największą zaletą REST jest oderwanie się od architektur RPC. REST ujawnia zasoby, a nie procesy. Pozwala to stworzyć luźno związany system, w którym zmiany, ulepszenia, a nawet awarie jednej części mają ograniczony (negatywny) wpływ na inne części.

Niestety częstym niewłaściwym wykorzystaniem REST jest ujawnianie wewnętrznych struktur danych (w najgorszych przypadkach jest to CRUD bazy danych, hmm). To sprawia, że bardzo trudno jest to zrobić bezpiecznie. „Właściwe” użycie polega na odsłonięciu obiektów wysokiego poziomu, które są istotne dla części obsługiwanego systemu, i swobodnie zwraca kody błędów w przypadku każdej niezgodności.

Kolejną często pomijaną częścią REST jest idempotencja większości czasowników. Nie tylko GET, ale także PUT i DELETE powinny być dokładnie takie same, jeśli zostaną zastosowane raz lub kilka razy (możesz zwrócić 404, jeśli już został usunięty, lub „bez zmian”, jeśli klient PUT to samo). Prowadzi to do niezawodnych systemów i mniejszej współzależności dokładnych interpretacji semantyki.

Standardy WS- * naprawdę dotyczą głównie uruchamiania RPC przez SOAP / HTTP. Tak więc całe myślenie dotyczące CORBA i J2EE i ich poprzedników przeszło głównie na robienie tego samego rodzaju rzeczy w XML. Oznacza to takie rzeczy, jak deklaracje typu i umowy serwisowe, wymiana metadanych, deklaratywne bezpieczeństwo itp. Wszystkie te prawdziwe „korporacyjne” rzeczy. Szczerze mówiąc, jest nadmiernie wykorzystywany nawet w przedsiębiorstwie.

Ludziom budującym aplikację internetową taką jak ty, prawie na pewno lepiej byłoby użyć architektury RESTful. Prawie każda platforma może to zużywać i robić to w prosty sposób, nie martwiąc się o to, której wersji używasz specyfikacji i niezliczonych dziwactw konwersji specyficznych dla narzędzi itp.

Jedyną dużą zaletą SOAP w porównaniu z obecnymi implementacjami REST jest to, że SOAP jest łatwiejszy w obsłudze - większość klientów RESTful wymaga ode mnie zrozumienia interfejsu i napisania jakiegoś klienta. W przypadku protokołu SOAP po prostu wskazuję na niego plik wsdl.exe i generuje on dla mnie klasy.