Po co nam RESTful Web Services?

Reszta została rozpoczęta, według mojej wiedzy, przez rozprawę Roya Fieldinga style architektoniczne i projektowanie sieciowych Architektur oprogramowania, która jest warta przeczytania, jeśli na nią nie spojrzałeś.

Na górze dysertacji jest cytat:

prawie każdy czuje spokój z naturą: słuchając Oceanu fale na brzegu, przy spokojnym jeziorze, na polu trawy, na windblown heath. Pewnego dnia, kiedy nauczyliśmy się ponadczasowej drogi znowu my będziemy czuć to samo o naszych miastach, a my będziemy czuć jak dużo w nich spokoju, jak to czynimy dzisiaj idąc przez ocean, czy rozciągnięty w długiej trawie łąki.

- Christopher Alexander, ponadczasowy sposób budowania (1979)

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

SOAP jest protokołem opartym na HTTP, więc omija wiele konwencji HTTP, aby budować nowe konwencje w SOAP i jest na wiele sposobów zbędny z HTTP. HTTP jest jednak więcej niż wystarczający do ponownego przetwarzania, wyszukiwania, pisania i usuwania informacji za pośrednictwem HTTP, a to wiele z tego, czym jest REST. Ponieważ REST jest zbudowany z HTTP, a nie 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ć najszerzej rozumiany i zintegrowany-z protokołem w użyciu w tym momencie.

From here :

Zalety odpoczynku:

• Lightweight-niewiele dodatkowych znaczników xml
• Wyniki Czytelne Dla Człowieka
• Łatwy w budowie-nie wymaga zestawów narzędzi

Zobacz też to out:

Aby być uczciwym, odpoczynek nie jest najlepszym rozwiązaniem dla każdego serwisu internetowego. Dane, które muszą być bezpieczne, nie powinny być wysyłane jako parametry w Uri. I duże ilości danych, np. w szczegółowych zleceniach zakupu, mogą szybko stają się uciążliwe lub nawet poza granicami w URI. W takich przypadkach mydło jest rzeczywiście solidnym rozwiązaniem. Ale ważne jest, aby najpierw spróbować odpocząć i uciekać się do mydła 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 to jest najlepszy link, aby zacząć od odpoczynku od zera! http://www.codeproject.com/Articles/21174/Everything-About-REST-Web-Services-What-and-How-Pa

Just to pull you in,

Pomyśl, czym jest "tradycyjny serwis internetowy". Jest to interfejs z exposed " metody."Klienci znają nazwę, Dane wejściowe i wyjściowe metod i dlatego można je nazwać.

Teraz wyobraź sobie interfejs, który nie ujawnia "metod". Zamiast tego eksponuje "przedmioty". Więc kiedy klient widzi ten interfejs, wszystko, co widzi jest jednym lub więcej "obiektów". "Obiekt" nie ma wejścia ani wyjścia – bo "nic nie robi". To rzeczownik, a nie czasownik. To jest " a rzecz", a nie "działanie".

Na przykład pomyśl o tradycyjnym serwisie internetowym, który zapewnia aktualne warunki pogodowe, jeśli podasz mu miasto. Prawdopodobnie posiada metodę webową taką jak GetWeatherInfo (), która zajmuje miasto jako wejście i dostarcza dane pogodowe jako wyjście. Do tej pory łatwo jest ci zrozum, w jaki sposób klient będzie korzystał z tej usługi internetowej.

Teraz wyobraź sobie, że w miejsce powyższego serwisu internetowego istnieje nowy to eksponuje miasta jako obiekty. Więc, kiedy patrzysz na to jak na klienta, zamiast GetWeatherInfo () widzisz Nowy Jork, Dallas, Los Angeles, Londyn i tak dalej. A te miasta nie mają żadnego zastosowania specyficznych metod - są one najwyraźniej jak inert gazy - same nie reagują.

Musisz myśleć-cóż, jak to pomaga, jako klient, aby pogoda w Dallas? Dojdziemy do tego za kilka chwil.

Jeśli wszystko, co otrzymujesz z serwisu internetowego, to "zbiór obiektów" , oczywiście potrzebujesz sposobu, aby "działać na nich". Same obiekty nie posiadają metod aby zadzwonić, więc potrzebujesz zestawu działań, które możesz zastosować na te obiekty. Innymi słowy, musisz " zastosować czasownik do rzeczownik". Jeśli widzisz przedmiot, powiedzmy jabłko, który jest "rzeczownikiem", możesz zastosować "czasownik" jak jeść, do niego. Ale nie wszystkie czasowniki można zastosować do wszystkich rzeczowniki. Możesz prowadzić samochód, ale nie możesz prowadzić telewizora.

Tak więc, jeśli serwis internetowy eksponuje tylko obiekty – a Ty zostaniesz poproszony-dobrze, zaprojektujmy teraz kilka standardowych działań lub czasowników, które " wszyscy klienci can apply to all objects they see",...

Większość Odpowiedzi " pro " na temat REST wydaje się pochodzić od ludzi, którzy nigdy nie opracowali usługi internetowej lub klienta mydła za pomocą środowiska, które dostarcza odpowiednich narzędzi do zadania. Narzekają na problemy, z którymi po prostu nigdy się nie spotkałem, używając Visual Studio. NET i Rational Web Developer IBM. Przypuszczam, że jeśli musisz rozwijać usługi internetowe lub klientów w języku skryptowym, lub innym języku z niewielką lub żadną obsługą narzędzi, że są one ważne skargi.

Muszę również przyznać, że kilka punktów " pro " brzmi jak rzeczy, które mogą być rzeczywiście prawdziwe - ale nigdy nie widziałem przykładu, który ilustruje ich wartość. W szczególności byłbym bardzo wdzięczny, gdyby ktoś opublikował komentarz zawierający link do dobrego przykładu serwisu internetowego REST. Powinien to być taki, który używa wielu poziomów zasobów, być może w hierarchii, i który prawidłowo używa typów mediów. Może jeśli spojrzę na dobry przykład, zrozumiem, w wrócę tu i się przyznam.

Aby dodać nieco prozaiczny spin do odpowiedzi już podanych powodem, dla którego korzystamy z usług REST, GDZIE JESTEM, jest to, że jeśli wiesz, że możesz podać partnerowi biznesowemu adres URL i wiesz, że otrzyma w zamian ładnie ułożoną płytę XML, bez względu na to, czy pracują w.Net x.X, PHP, Python, Java, Ruby czy Bóg wie, co to znacznie zmniejsza bóle głowy.

Oznacza to również, że na koniec non-techy nasi handlowcy mogą pochwalić się naszym wszechstronnym API ludziom bez obaw o szukanie jak kompletne Muppety.

Wiele poza korzyściami technicznymi wszystko, co jest łatwe dla niemechaników, aby wyjaśnić, zademonstrować i czuć się pewnie, jest dobrą rzeczą. Mydło, choć równie fajne dla techników, jest znacznie mniej przystępne dla nie-techników i dlatego nie jest tak łatwe do"sprzedania".

Mam tendencję do zauważania, że rzeczy, które nie-technicy mogą mieć głowę wokół głowy, mają tendencję do przyklejania się. Wątpię więc, by odpoczynek był tak podatny jak mydło na kaprysy mody.

Ale wszystkie rzeczy o nie umieszczaniu niczego w serwisie odpoczynku, które powinny być zablokowane, są podwójnie prawdziwe, choćby dlatego, że technologia jest tak łatwo zrozumiała przez ludzi, którzy nie są tak technicznie nastawieni.

Oto kilka pomysłów:

• REST ogranicza usługę do korzystania z jednolitego interfejsu. Nie musisz tracić czasu na marzenia (lub kłótnie) na temat wszystkich możliwych sposobów działania usługi - masz prawo do pracy, identyfikując zasoby w systemie. Okazuje się, że jest to duża praca sama w sobie, ale na szczęście problemy wydają się być znacznie lepiej zdefiniowane.
Z zasobami, ich stowarzyszeniami i ich reprezentacjami w ręku, naprawdę niewiele można zrobić w wdrożenie usługi, ponieważ wiele decyzji zostało podjętych za Ciebie.
• 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 do omawiania problemów projektowych z innymi programistami, a nawet z tymi mniej technicznie myślącymi (takimi jak klienci).
• Jak mówi Darrel, ponieważ używasz projektu hipertekstowego , Twoja usługa zawęża zakres sprzężenia tylko jedno-typy mediów. Pomaga to jako programista, ponieważ zmiany w systemie są zawarte w wąskim paśmie kontaktu. Pomaga to Twoim klientom w tym, że mniej zmian złamie ich kod.
• prawie każdy problem, jaki możesz mieć przy implementacji REST, może zostać rozwiązany przez ujawnienie nowego zasobu lub ponowne przemyślenie modelu zasobu. Ten nacisk jest, IMO, duży wzrost wydajności.

Podsumowując, reszta usuwa wiele najbardziej czasochłonnych i kontrowersyjne decyzje projektowe i wdrożeniowe z przepływu pracy Twojego zespołu. To przesuwa twoją uwagę od wdrożenia Twojej usługi do zaprojektowania it. I robi to bez konieczności łączenia się z protokołem HTTP.

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, prosty HTTP jest używany do wykonywania połączeń między maszynami.

Pod wieloma względami sama sieć WWW, oparta na HTTP, może być postrzegana jako architektura oparta na REST. Aplikacje RESTful używają żądań HTTP do publikowania danych( tworzenia i / lub aktualizacji), odczytywania danych (np. tworzenia zapytań) i usuwania danych. Tak więc REST używa HTTP dla wszystkie cztery operacje CRUD (Create / Read/Update/Delete).

REST jest lekką alternatywą dla mechanizmów takich jak RPC (Remote Procedure Calls) i usług internetowych (SOAP, WSDL, et al.). Później zobaczymy, o ile prostszy jest odpoczynek.

Pomimo tego, że jest prosty, REST jest w pełni funkcjonalny; zasadniczo nie ma nic, co można zrobić w serwisach internetowych, czego nie można zrobić z architekturą RESTful. Odpoczynek nie jest "standardem". Nigdy nie będzie rekomendacji W3C na np. odpoczynek. I podczas istnieją frameworki programistyczne REST, praca z REST jest tak prosta, że często można "tworzyć własne" funkcje bibliotek standardowych w językach takich jak Perl, Java lub C#.