RESZTA
Rozumiem, że główna idea REST jest niezwykle prosta. Od lat korzystamy z przeglądarek internetowych i przekonaliśmy się, jak łatwe, elastyczne, skuteczne itp. Są strony internetowe. Witryny HTML używają hiperłączy i formularzy jako podstawowego sposobu interakcji użytkownika. Ich głównym celem jest umożliwienie nam, klientom, poznania tylko tych linków, których możemy używać w obecnym stanie . A REST po prostu mówi „dlaczego nie zastosować tych samych zasad do kierowania komputerem, a nie ludzkimi klientami za pośrednictwem naszej aplikacji?” Połącz to z mocą infrastruktury WWW, a otrzymasz narzędzie do tworzenia świetnych aplikacji rozproszonych.
Innym możliwym wytłumaczeniem są ludzie matematycznie myślący. Każda aplikacja jest w zasadzie maszyną stanową, a operacje logiczne są przejściami stanu. Ideą REST jest mapowanie każdego przejścia na jakieś żądanie do zasobu i zapewnienie klientom łączy reprezentujących przejścia dostępne w bieżącym stanie. W ten sposób modeluje maszynę stanową za pomocą reprezentacji i łączy. Dlatego nazywa się to REpresentational State Transfer.
To dość zaskakujące, że wszystkie odpowiedzi wydają się koncentrować albo na formacie wiadomości, albo na użyciu czasowników HTTP. W rzeczywistości format komunikatu nie ma żadnego znaczenia, REST może użyć dowolnego, pod warunkiem, że programista go udokumentuje. Czasowniki HTTP sprawiają, że usługa jest usługą CRUD, ale jeszcze nie jest RESTful. To, co naprawdę zmienia usługę w usługę REST, to hiperłącza (inaczej formanty hipermedia) osadzone w odpowiedziach serwera wraz z danymi, a ich ilość musi być wystarczająca, aby każdy klient mógł wybrać następne działanie z tych łączy.
Niestety, raczej trudno jest znaleźć prawidłowe informacje na temat REST w Internecie, z wyjątkiem tezy Roya Fieldinga . (To on opracował REST). Polecam „Rest in Practice” książki , ponieważ daje kompleksowy poradnik krok po kroku, w jaki sposób ewoluują od mydła na odpoczynek.
MYDŁO
Jest to jedna z możliwych form stylu architektury RPC (Remote Procedural Call). Zasadniczo jest to tylko technologia, która pozwala klientom wywoływać metody serwera przez granice usług (sieć, procesy itp.) Tak, jakby wywoływali metody lokalne. Oczywiście tak naprawdę różni się od wywoływania metod lokalnych szybkością, niezawodnością i tak dalej, ale pomysł jest taki prosty.
W porównaniu
Szczegóły, takie jak protokoły transportu, formaty komunikatów, xsd, wsdl itp. Nie mają znaczenia przy porównywaniu dowolnej formy RPC z REST. Główną różnicą jest to, że usługa RPC zmienia styl roweru, projektując własny protokół aplikacji w interfejsie RPC API z semantyką, którą zna tylko on. Dlatego wszyscy klienci muszą zrozumieć ten protokół przed skorzystaniem z usługi i nie można zbudować ogólnej infrastruktury, takiej jak pamięci podręczne, z powodu zastrzeżonej semantyki wszystkich żądań. Ponadto interfejsy API RPC nie sugerują, jakie działania są dozwolone w bieżącym stanie, należy to wywnioskować z dodatkowej dokumentacji. Z drugiej strony REST wymaga użycia jednolitych interfejsów, aby umożliwić różnym klientom zrozumienie semantyki API oraz kontroli hipermedialnych (linków) w celu wyróżnienia dostępnych opcji w każdym stanie. A zatem,
W pewnym sensie SOAP (jak każde inne RPC) jest próbą tunelowania przez granicę usługi, traktując łączące się media jako czarną skrzynkę zdolną do przesyłania tylko komunikatów. REST jest decyzją o uznaniu, że sieć jest ogromnym, rozproszonym systemem informacyjnym, aby zaakceptować świat takim, jaki jest, i nauczyć się go opanowywać zamiast z nim walczyć.
SOAP wydaje się być świetny do wewnętrznych interfejsów API sieci, gdy kontrolujesz zarówno serwer, jak i klientów, a interakcje nie są zbyt skomplikowane. Używanie go przez programistów jest bardziej naturalne. Jednak w przypadku publicznego interfejsu API, który jest używany przez wiele niezależnych podmiotów, jest złożony i duży, REST powinien pasować lepiej. Ale to ostatnie porównanie jest bardzo rozmyte.
Aktualizacja
Moje doświadczenie nieoczekiwanie pokazało, że rozwój REST jest trudniejszy niż SOAP. Przynajmniej dla .NET. Chociaż istnieją świetne frameworki, takie jak ASP.NET Web API, nie ma narzędzi, które automatycznie generowałyby proxy po stronie klienta. Nie ma to jak „Dodaj odniesienie do usługi sieci Web” lub „Dodaj odniesienie do usługi WCF”. Należy ręcznie napisać cały kod serializacji i zapytania o usługę. I stary, to dużo kodu z podstawowymi danymi. Myślę, że rozwój REST potrzebuje czegoś podobnego do WSDL i implementacji narzędzi dla każdej platformy programistycznej. W rzeczywistości wydaje się, że istnieje dobry grunt: WADL lub WSDL 2.0 , ale żaden ze standardów nie wydaje się być dobrze obsługiwany.
Aktualizacja (styczeń 2016 r.)
Okazuje się, że istnieje szeroka gama narzędzi do definiowania interfejsu API REST. Moje osobiste preferencje to obecnie RAML .
Jak działają usługi sieciowe?
To zbyt szerokie pytanie, ponieważ zależy od architektury i technologii zastosowanej w konkretnej usłudze internetowej. Ale ogólnie rzecz biorąc, usługa internetowa to po prostu aplikacja w sieci, która może przyjmować żądania od klientów i zwracać odpowiedzi. Jest narażony na działanie Internetu, dlatego jest usługą internetową i zazwyczaj jest dostępny 24 godziny na dobę, 7 dni w tygodniu, dlatego jest to usługa . Oczywiście rozwiązuje to pewien problem (inaczej dlaczego ktoś miałby kiedykolwiek korzystać z usługi internetowej) dla swoich klientów.
