Dlaczego potrzebujemy RESTful Web Services?

Mam zamiar nauczyć się usług internetowych RESTful (lepiej powiedzieć, że będę musiał to zrobić, ponieważ jest to część programu studiów magisterskich CS).

Przeczytałem trochę informacji w Wikipedii, a także przeczytałem artykuł o REST w Sun Developer Network i widzę, że nie jest to łatwa technologia, istnieją specjalne ramy do tworzenia aplikacji RESTful i często jest porównywana z usługami sieciowymi SOAP i Programista powinien wiedzieć, kiedy używać SOAP, a kiedy REST może być dobrym podejściem.

Pamiętam, że kilka lat temu SOAP był bardzo popularny (modny?) I pozycja „MYDŁO” musiała się znaleźć w każdym dobrym CV. Ale w praktyce był używany bardzo rzadko i do bardzo prostych celów.

Wydaje mi się, że REST to kolejne „ostatnie słowo mody” (albo całkowicie się mylę, bo w praktyce nigdy nie widziałem REST).

Czy możesz mi podać kilka przykładów, kiedy należy użyć REST i dlaczego nie możemy zrobić tego samego bez REST (lub dlaczego powinniśmy spędzać dużo więcej czasu, aby robić to samo bez REST)?

UPD : Niestety nie widzę żadnych konkretnych argumentów, które mogłyby zaskoczyć mnie w pierwszych komentarzach. Pomyśl, że REST to niesamowita technologia!

Chciałbym zobaczyć takie odpowiedzi:

Pracowałem nad kolejną złożoną aplikacją HelloWorld i musimy przesłać dużo / malutkich danych i zaproponowałem rozwiązanie REST mojemu współpracownikowi:

- No cholera! Jonny, z pewnością powinniśmy użyć REST do implementacji tej aplikacji!
- Tak, Billy, możemy użyć REST, ale lepiej byłoby użyć SOAP. Zaufaj mi, bo wiem coś o tworzeniu aplikacji HelloWorld.
- Ale SOAP to staromodna technologia ubiegłego wieku i możemy użyć lepszej.
- Billy, czy jesteś gotów spędzić 3 dni na eksperymentowaniu z REST? Możemy to zrobić z SOAP w 2 godziny ..
- Tak, jestem pewien, że poświęcimy jeszcze więcej czasu na osiągnięcie takiego samego bezpieczeństwa / wydajności / / skalowalności / cokolwiek innego z SOAP. Jestem pewien, że aplikacje HelloWorld powinny być od teraz rozwijane tylko przy pomocy REST.

REST należy używać, jeśli bardzo ważne jest, aby zminimalizować sprzężenie między komponentami klienta i serwera w aplikacji rozproszonej.

Może tak być w przypadku, gdy serwer będzie używany przez wielu różnych klientów , nad którymi nie masz kontroli. Może tak być również w przypadku, gdy chcesz mieć możliwość regularnej aktualizacji serwera bez konieczności aktualizowania oprogramowania klienta.

Mogę Państwa zapewnić, że osiągnięcie tak niskiego poziomu sprzężenia nie jest łatwe . Aby odnieść sukces, należy przestrzegać wszystkich ograniczeń REST. Utrzymanie czysto bezpaństwowego połączenia jest trudne. Wybieranie odpowiednich typów mediów i wyciskanie danych do formatów jest trudne. Tworzenie własnych typów multimediów może być jeszcze trudniejsze.

Dostosowanie bogatego zachowania serwera do jednolitego interfejsu HTTP może być mylące, a czasami wydaje się pedantyczne w porównaniu ze stosunkowo prostym podejściem RPC.

Pomimo trudności, korzyści są takie, że masz usługę, którą deweloper klienta powinien być w stanie łatwo zrozumieć dzięki konsekwentnemu stosowaniu protokołu HTTP. Usługa powinna być łatwo wykrywalna dzięki hipermediom, a klient powinien być wyjątkowo odporny na zmiany na serwerze .

Zalety hipermediów i unikanie stanu sesji sprawiają, że równoważenie obciążenia jest proste, a partycjonowanie usług jest wykonalne . Ścisła zgodność z regułami HTTP sprawia, że ​​dostępność narzędzi takich jak debuggery i buforujące proxy jest wspaniałą rzeczą.

Aktualizacja

Wydaje mi się, że REST to kolejne „ostatnie słowo mody” (albo całkowicie się mylę, bo w praktyce nigdy nie widziałem REST).

Myślę, że REST stał się modny, ponieważ ludzie próbujący robić projekty typu SOA odkryli, że używając stosu SOAP nie zdają sobie sprawy z obiecanych korzyści. Ludzie wracają do sieci jako przykładu prostych metod integracji. Niestety, myślę, że ludzie nie doceniają ilości planowania i przewidywania, które włożono w tworzenie sieci, i nadmiernie upraszczają to, co należy zrobić, aby umożliwić tego rodzaju nieoczekiwane ponowne wykorzystanie, które ma miejsce w sieci.

Mówisz, że nigdy nie widziałeś REST w praktyce, ale to nie może być prawdą, jeśli kiedykolwiek korzystasz z przeglądarki internetowej. Przeglądarka internetowa jest klientem REST.

• Dlaczego nie trzeba aktualizować przeglądarki, gdy ktoś zmienia kod HTML na stronie internetowej?
• Dlaczego mogę dodać kompletny nowy zestaw stron do witryny internetowej, a „klient” może nadal uzyskiwać dostęp do tych nowych stron bez aktualizacji?
• Dlaczego nie muszę podawać „service-description-language” do przeglądarki internetowej, aby poinformować ją, kiedy przejdzie do http://example.org/images/cat, że typem zwracanym będzie obraz jpeg i kiedy przejdziesz dla http://example.org/description/cat typem zwracanym będzie text / html?
• Dlaczego mogę używać przeglądarki internetowej do odwiedzania witryn, które nie istniały w chwili wydania przeglądarki? Skąd klient może wiedzieć o tych witrynach?

To może brzmieć jak głupie pytania, ale jeśli znasz odpowiedź, możesz zacząć rozumieć, o co chodzi w REST. Spójrz na StackOverflow, aby uzyskać więcej korzyści z REST. Kiedy patrzę na pytanie, mogę dodać tę stronę do zakładek lub wysłać adres URL do znajomego, a on widzi te same informacje. Nie musi przeglądać witryny, aby znaleźć to pytanie.

StackOverflow korzysta z różnych usług OpenId do uwierzytelniania, gravatar.com dla obrazów awatarów, google-analytics i Quantserve do informacji analitycznych. Ten rodzaj integracji wielu firm jest czymś, o czym świat SOAP tylko marzy . Jednym z najlepszych przykładów jest fakt, że biblioteki jQuery używane do obsługi interfejsu użytkownika StackOverflow są pobierane z sieci dostarczania treści Google. Fakt, że SO może nakierować klienta (tj. Twoją przeglądarkę internetową), aby pobrać kod z witryny innej firmy w celu poprawy wydajności, świadczy o niskim sprzężeniu między klientem sieciowym a serwerem.

Oto przykłady działającej architektury REST.

Teraz niektóre witryny / aplikacje internetowe łamią zasady REST i przeglądarka nie działa zgodnie z oczekiwaniami.

• Niesławny problem z przyciskiem Wstecz jest spowodowany użyciem stanu sesji po stronie serwera.
• Równoważenie obciążenia może stać się uciążliwe, gdy masz stan sesji po stronie serwera.
• Aplikacje Flash często uniemożliwiają adresowi URL identyfikację konkretnej reprezentacji.
• Innym problemem, który łamie przeglądarki internetowe, jest słaba zgodność ze standardami mediów. Cały czas słyszymy o tym, jak należy zabić IE6. Problem polega na tym, że standardy nie były odpowiednio przestrzegane lub zostały zignorowane z jakiegokolwiek powodu.
• Korzystanie z sesji logowania jest źródłem wielu luk w zabezpieczeniach.

REST jest wszędzie. To ta część sieci, która sprawia, że ​​działa dobrze. Jeśli chcesz tworzyć aplikacje rozproszone, które można skalować jak sieć, być odpornym na zmiany, podobnie jak sieć i promować ponowne wykorzystanie, tak jak w przypadku sieci, postępuj zgodnie z tymi samymi zasadami, które stosowano podczas tworzenia przeglądarek internetowych.

O ile wiem, REST zapoczątkowała rozprawa Roya Fieldinga Architectural Styles and the Design of Network-based Software Architectures , którą warto przeczytać, jeśli się na nią nie spojrzał.

U góry rozprawy znajduje się cytat:

Prawie każdy czuje spokój z naturą: słucha się fal oceanu na brzegu, nad spokojnym jeziorem, na łące trawy, na wietrznych wrzosowiskach. Pewnego dnia, kiedy ponownie nauczymy się ponadczasowego sposobu, będziemy czuć to samo w naszych miastach i będziemy w nich tak samo spokojni, jak dziś spacerując nad oceanem lub wyciągnięci w wysokiej trawie łąka.

- Christopher Alexander, Ponadczasowa droga budowania (1979)

I to naprawdę podsumowuje to. REST jest pod wieloma względami bardziej elegancki.

SOAP jest protokołem uzupełniającym HTTP, więc omija wiele konwencji HTTP przy tworzeniu nowych konwencji w SOAP i jest pod wieloma względami nadmiarowy w przypadku HTTP. Jednak protokół HTTP jest więcej niż wystarczający do pobierania, wyszukiwania, zapisywania i usuwania informacji za pośrednictwem protokołu HTTP, a na tym właśnie polega REST. Ponieważ REST jest zbudowany z HTTP zamiast na nim, oznacza to również, że oprogramowanie, które chce się z nim zintegrować (takie jak przeglądarka internetowa), nie musi rozumieć SOAP, aby to zrobić, tylko HTTP, który musi być najbardziej szeroko rozumiany i zintegrowany z protokołem używanym w tym momencie.

Od tutaj :

Zalety REST:

• Lekki - niewiele dodatkowych znaczników XML
• Wyniki czytelne dla człowieka
• Łatwy w budowie - nie są wymagane żadne zestawy narzędzi

Sprawdź również to :

Szczerze mówiąc, REST nie jest najlepszym rozwiązaniem dla każdej usługi internetowej. Dane, które muszą być bezpieczne, nie powinny być przesyłane jako parametry w identyfikatorach URI. A duże ilości danych, na przykład w szczegółowych zamówieniach, mogą szybko stać się uciążliwe lub nawet wykraczać poza granice identyfikatora URI. W takich przypadkach SOAP jest rzeczywiście solidnym rozwiązaniem. Ale ważne jest, aby najpierw wypróbować REST i uciekać się do SOAP tylko wtedy, gdy jest to konieczne. Dzięki temu tworzenie aplikacji jest proste i dostępne.

Mogę śmiało powiedzieć, że spędziłem dużo czasu, aby zrozumieć to jako początkujący, ale jest to najlepszy link do rozpoczęcia od podstaw REST! http://www.codeproject.com/Articles/21174/Everything-About-REST-Web-Services-What-and-How-Pa

Tylko żeby cię wciągnąć

Pomyśl, czym jest „tradycyjna usługa internetowa”. Jest to interfejs z ujawnionymi „metodami”. Klienci znają nazwy metod, dane wejściowe i wyjściowe, dlatego mogą je wywołać.

Teraz wyobraź sobie interfejs, który nie ujawnia „metod”. Zamiast tego eksponuje „obiekty”. Więc kiedy klient widzi ten interfejs, widzi tylko jeden lub więcej „obiektów”. „Obiekt” nie ma wejścia ani wyjścia - ponieważ „nic nie robi”. To rzeczownik, a nie czasownik. To jest „rzecz”, a nie „działanie”.

Na przykład pomyśl o tradycyjnej usłudze internetowej, która podaje aktualne warunki pogodowe, jeśli podasz jej miasto. Prawdopodobnie ma metodę internetową, taką jak GetWeatherInfo (), która pobiera miasto jako dane wejściowe i dostarcza dane o pogodzie jako dane wyjściowe. Jak dotąd łatwo jest zrozumieć, w jaki sposób klient będzie korzystał z tej usługi internetowej.

A teraz wyobraź sobie, że zamiast powyższej usługi internetowej istnieje nowa usługa, która eksponuje miasta jako obiekty. Kiedy więc spojrzysz na to jako na klienta, zamiast na GetWeatherInfo (), zobaczysz Nowy Jork, Dallas, Los Angeles, Londyn i tak dalej. A miasta te nie mają zwisających z nich metod specyficznych dla aplikacji - pozornie są jak gazy obojętne - same nie reagują.

Pewnie się zastanawiasz - cóż, w jaki sposób to pomaga tobie, jako klientowi, poznać pogodę w Dallas? Dojdziemy do tego za kilka chwil.

Jeśli wszystko, co otrzymujesz z usługi internetowej, to „zestaw obiektów”, oczywiście potrzebujesz sposobu, aby „działać na nich”. Same obiekty nie mają żadnych metod do wywołania, więc potrzebujesz zestawu działań, które możesz zastosować do tych obiektów. Innymi słowy, musisz „zastosować czasownik do rzeczownika”. Jeśli zobaczysz obiekt, powiedzmy, jabłko, które jest „rzeczownikiem”, możesz zastosować do niego „czasownik”, np. Jeść. Ale nie wszystkie czasowniki można zastosować do wszystkich rzeczowników. Na przykład możesz prowadzić samochód, ale nie możesz prowadzić telewizora.

Tak więc, jeśli usługa sieciowa udostępnia tylko obiekty, a zostaniesz zapytany - cóż, zaprojektujmy teraz kilka standardowych działań lub czasowników, które „wszyscy klienci mogą zastosować do wszystkich obiektów, które widzą”, ...

Oto kilka pomysłów:

• REST ogranicza usługę do korzystania z jednolitego interfejsu. Nie musisz tracić czasu na marzenia (lub kłótnie) o wszystkich możliwych sposobach działania Twojej usługi - zaczynasz od razu identyfikować zasoby w swoim systemie. Samo w sobie okazuje się dużym zadaniem, ale na szczęście problemy są zwykle znacznie lepiej zdefiniowane.
• Mając w ręku zasoby, ich stowarzyszenia i reprezentacje, naprawdę niewiele jest do zrobienia we wdrażaniu Twojej usługi, ponieważ podjęto za Ciebie wiele decyzji.
• Twój system będzie wyglądał bardzo podobnie do innych systemów RESTful; krzywe uczenia się dla członków zespołu, partnerów i klientów zostaną zredukowane.
• Będziesz miał wspólne słownictwo umożliwiające omawianie problemów projektowych z innymi programistami, a nawet z tymi, którzy są mniej techniczni (np. Klienci).
• Jak mówi Darrel, ponieważ używasz projektu opartego na hipertekstie , twoja usługa zawęża zakres sprzężenia tylko do jednej rzeczy - typów mediów. Pomaga to programistom, ponieważ zmiany w systemie są zawarte w wąskim zakresie kontaktów. Pomaga to Twoim klientom w tym, że mniej zmian złamie ich kod.
• Prawie każdy problem, jaki możesz mieć podczas wdrażania REST, można rozwiązać, ujawniając nowy zasób lub ponownie przemyślając model zasobów. Celem jest, IMO, duży wzrost produktywności.

Podsumowując, REST usuwa wiele najbardziej czasochłonnych i spornych decyzji projektowych i wdrożeniowych z przepływu pracy Twojego zespołu. Przenosi twoją uwagę z wdrażania usługi na projektowanie . I robi to bez wrzucania gobbledygooka do protokołu HTTP.

Większość odpowiedzi „pro” dotyczących REST wydaje się pochodzić od osób, które nigdy nie opracowały usługi sieciowej SOAP ani klienta używającego środowiska dostarczającego odpowiednich narzędzi do tego zadania. Narzekają na problemy, których po prostu nigdy nie napotkałem, korzystając z Visual Studio .NET i IBM Rational Web Developer. Przypuszczam, że jeśli musisz tworzyć usługi sieciowe lub klientów w języku skryptowym lub innym języku z niewielkim wsparciem narzędziowym lub bez niego, to są to uzasadnione skargi.

Muszę też przyznać, że kilka „za” punktów brzmi jak rzeczy, które mogą być prawdą - ale nigdy nie widziałem przykładu ilustrującego ich wartość. W szczególności byłbym bardzo wdzięczny, gdyby ktoś zamieścił komentarz zawierający łącze do dobrego przykładu usługi internetowej REST. Powinien to być taki, który wykorzystuje wiele poziomów zasobów, prawdopodobnie w hierarchii, i który prawidłowo wykorzystuje typy mediów. Może jeśli spojrzę na dobry przykład, zrozumiem, w takim przypadku wrócę tutaj i przyznam się do tego.

Aby dodać nieco prozaiczne podejście do odpowiedzi już podanych, powód, dla którego korzystamy z usług REST, w którym jestem, jest taki, że jeśli wiesz, że możesz wręczyć partnerowi biznesowemu adres URL i wiesz, że otrzyma on w zamian ładnie rozplanowaną płytę XML bez względu na to, czy pracują w .Net xx, PHP, Python, Java, Ruby, czy też Bóg wie, co znacznie zmniejsza bóle głowy.

Oznacza to również, że w sprawach niezwiązanych z technologią nasi sprzedawcy mogą pochwalić się naszym wszechstronnym interfejsem API ludziom bez obawy, że będą wyglądać jak kompletne muppety.

Poza korzyściami technicznymi wszystko, co nietechnikowi łatwo wytłumaczyć, zademonstrować i poczuć się pewnie, jest dobrą rzeczą. MYDŁO, chociaż równie fajne dla techników, jest znacznie mniej przystępne dla osób nie będących specjalistami i dlatego nie jest tak łatwe do „sprzedania”.

Zwykle zauważam, że rzeczy, które nie są technikami, mają tendencję do trzymania się głowy. Dlatego wątpię, że REST jako technika może być tak samo podatna na kaprysy mody jak mydło.

Ale wszystkie rzeczy dotyczące nie umieszczania niczego w usłudze REST, która powinna zostać zablokowana, są podwójnie prawdziwe, choćby dlatego, że technologia jest tak łatwa do zrozumienia dla ludzi, którzy nie są tak techniczni.

REST to styl architektury do projektowania aplikacji sieciowych. Chodzi o to, że zamiast używać złożonych mechanizmów, takich jak CORBA, RPC lub SOAP do łączenia się między maszynami, do wykonywania połączeń między maszynami używany jest prosty protokół HTTP.

Pod wieloma względami samą sieć World Wide Web, opartą na protokole HTTP, można postrzegać jako architekturę opartą na REST. Aplikacje RESTful używają żądań HTTP do wysyłania danych (tworzenia i / lub aktualizacji), odczytywania danych (np. Tworzenia zapytań) i usuwania danych. W związku z tym REST używa protokołu HTTP do wszystkich czterech operacji CRUD (tworzenie / odczytywanie / aktualizowanie / usuwanie).

REST to lekka alternatywa dla mechanizmów takich jak RPC (Remote Procedure Calls) i Web Services (SOAP, WSDL i in.). Później zobaczymy, o ile prostszy jest REST.

Pomimo swojej prostoty, REST jest w pełni funkcjonalny; w usługach sieci Web w zasadzie nic nie można zrobić z architekturą zgodną z REST. REST nie jest „standardem”. Na przykład nigdy nie będzie rekomendacji W3C dla REST. I chociaż istnieją struktury programistyczne REST, praca z REST jest tak prosta, że ​​często można „tworzyć własne” za pomocą standardowych funkcji biblioteki w językach takich jak Perl, Java lub C #.