Jaka jest różnica między HTTP a REST?

Po przeczytaniu wielu informacji na temat różnic między REST i SOAP mam wrażenie, że REST to tylko jedno słowo na HTTP. Czy ktoś może wyjaśnić, jaką funkcjonalność REST dodaje do HTTP?

Uwaga : nie szukam porównania REST względem SOAP.

Aktualizacja : Dziękujemy za odpowiedzi. Teraz stało się dla mnie jasne, że REST jest tylko zbiorem reguł dotyczących używania HTTP. Dlatego zamieściłem dalsze informacje na temat zalet tych konwencji .

Uwaga : Teraz rozumiem znaczenie REST; jak zauważa Emil Iwanow , REST oznacza używanie HTTP tak, jak powinno być. Jednak nie jestem pewien, czy to zasługuje na swój własny termin, i na pewno nie mam wokół tego szumu.

Nie, REST jest sposób HTTP powinien być stosowany .

Dziś używamy tylko niewielkiej części metod protokołu HTTP - mianowicie GETi POST. Aby to zrobić, należy użyć wszystkich metod protokołu.

Na przykład REST dyktuje użycie DELETEdo wymazania dokumentu (czy to pliku, stanu itp.) Za URI, podczas gdy w przypadku HTTP niewłaściwie użyjesz zapytania GETlub POSTzapytania ...product/?delete_id=22.

HTTP to protokół używany do komunikacji, zwykle używany do komunikacji z zasobami internetowymi lub dowolną aplikacją z klientem przeglądarki internetowej.

REST oznacza, że ​​główną koncepcją używaną podczas projektowania aplikacji jest Zasób: dla każdej akcji, którą chcesz wykonać, musisz zdefiniować zasób, na którym zwykle wykonujesz tylko operację CRUD, co jest prostym zadaniem. w tym celu bardzo wygodne jest użycie 4 czasowników używanych w protokole HTTP przeciwko 4 operacjom CRUD (Get for Read, POST jest dla CREATE, PUT dla UPDATE i DELETE dla DELETE). to w przeciwieństwie do starszej koncepcji RPC (Remote Procedura Call), w której masz zestaw działań, które chcesz wykonać w wyniku wywołania użytkownika. jeśli zastanawiasz się na przykład, jak opisać facebooka jak w poście, z RPC możesz stworzyć usługi o nazwie AddLikeToPost i RemoveLikeFromPost i zarządzać nim wraz ze wszystkimi innymi usługami związanymi z postami na FB, więc nie będziesz musiał tworzyć specjalnych obiekt dla Like. z REST będziesz mieć obiekt Like, który będzie zarządzany osobno za pomocą funkcji Usuń i Utwórz. Oznacza to również, że będzie opisywać osobny byt w twojej bazie danych. może to wyglądać na niewielką różnicę, ale takie działanie zwykle daje znacznie prostszy kod i znacznie prostszą aplikację. przy takim projekcie większość logiki aplikacji jest oczywista ze struktury (modelu) obiektu, w przeciwieństwie do RPC, w której zwykle trzeba by wyraźnie dodać dużo więcej logiki.

projektowanie aplikacji RESTful jest zwykle o wiele trudniejsze, ponieważ wymaga opisania skomplikowanych rzeczy w prosty sposób. opisywanie wszystkich funkcjonalności przy użyciu tylko funkcji CRUD jest trudne, ale po wykonaniu tego Twoje życie byłoby o wiele prostsze i okaże się, że napiszesz o wiele krótsze metody.

Jeszcze jedną obecną architekturą REST ograniczającą jest nieużywanie kontekstu sesji podczas komunikacji z klientem (bezstanowy), co oznacza, że ​​wszystkie informacje muszą zrozumieć, kto jest klientem i czego chce, jest przekazywany wraz z wiadomością internetową. każde wywołanie funkcji ma charakter opisowy, nie ma wcześniejszej rozmowy z klientem, do której można odwoływać się w komunikacie. dlatego klient nie mógł powiedzieć „daj mi następną stronę”, ponieważ nie masz sesji do przechowywania poprzedniej strony i jakiego rodzaju strony chcesz, klient musiałby powiedzieć „mam na imię yuval, dostać me strona 2 określonego postu na określonym forum ". oznacza to, że w komunikacji musiałoby zostać przesłanych nieco więcej danych, ale pomyśl o różnicy między znalezieniem błędu zgłoszonego za pomocą funkcji „przejdź do następnej strony”, a nie „

Oczywiście jest o wiele więcej, ale moim zdaniem są to główne pojęcia w łyżeczce do herbaty.

HTTP to protokół aplikacji. REST to zestaw reguł, których przestrzeganie umożliwia budowanie aplikacji rozproszonej, która ma określony zestaw pożądanych ograniczeń.

Jeśli szukasz najbardziej znaczących ograniczeń usługi REST, które odróżniają aplikację RESTful od dowolnej aplikacji HTTP, powiedziałbym, że ograniczenie „samoopisania” i ograniczenie hipermedia (inaczej Hypermedia jako silnik stanu aplikacji (HATEOAS)) to najważniejsze.

Ograniczenie samoopisu wymaga, aby żądanie RESTful było całkowicie samoopisujące w intencji użytkowników. Umożliwia to pośrednikom (serwerom proxy i pamięci podręcznej) bezpieczne działanie na wiadomości.

Ograniczenie HATEOAS polega na przekształceniu aplikacji w sieć linków, w której aktualny stan klienta zależy od jego miejsca w tej sieci. Jest to podchwytliwa koncepcja i wymaga więcej czasu na wyjaśnienie niż obecnie.

Jak rozumiem, REST wymusza użycie dostępnych poleceń HTTP zgodnie z ich przeznaczeniem.

Na przykład mógłbym zrobić:

GET
http://example.com?method=delete&item=xxx

Ale z resztą użyłbym metody żądania „DELETE”, eliminując potrzebę param zapytania „metoda”

DELETE
http://example.com?item=xxx

Nie do końca...

http://en.wikipedia.org/wiki/Representational_State_Transfer

REST został początkowo opisany w kontekście HTTP, ale nie ogranicza się do tego protokołu. Architektury RESTful mogą być oparte na innych protokołach warstwy aplikacji, jeśli już zapewniają bogate i jednolite słownictwo dla aplikacji opartych na przekazywaniu znaczącego stanu reprezentacji. Aplikacje RESTful maksymalizują wykorzystanie wcześniej istniejącego, dobrze zdefiniowanego interfejsu i innych wbudowanych możliwości zapewnianych przez wybrany protokół sieciowy oraz minimalizują dodanie nowych funkcji specyficznych dla aplikacji.

http://www.looselycoupled.com/glossary/SOAP

(Simple Object Access Protocol) Standard wiadomości sieciowych. W oparciu o XML SOAP definiuje format kopert i różne reguły opisywania jego zawartości. Postrzegany (z WSDL i UDDI) jako jeden z trzech podstawowych standardów usług sieciowych, jest preferowanym protokołem do wymiany usług internetowych, ale w żadnym wypadku nie jest jedynym; zwolennicy REST twierdzą, że dodaje to niepotrzebnej złożoności.

REST to specyficzny sposób podejścia do projektowania dużych systemów (takich jak sieć).

Jest to zestaw „reguł” (lub „ograniczeń”).

HTTP to protokół, który próbuje przestrzegać tych reguł.

REST = Reprezentatywny transfer stanu

REST to zestaw reguł, których przestrzeganie umożliwia budowanie aplikacji rozproszonej, która ma określony zestaw pożądanych ograniczeń.

REST jest protokołem służącym do wymiany dowolnych komunikatów (XML, JSON itp.), Które mogą wykorzystywać HTTP do ich przesyłania.

Funkcje:

Jest bezstanowy, co oznacza, że ​​idealnie nie powinno się utrzymywać połączenia między klientem a serwerem. Klient jest odpowiedzialny za przekazanie swojego kontekstu do serwera, a następnie serwer może zapisać ten kontekst w celu przetworzenia dalszego żądania klienta. Na przykład sesja obsługiwana przez serwer jest identyfikowana przez identyfikator sesji przekazany przez klienta.

Zalety bezpaństwowości:

1. Usługi sieciowe mogą traktować każde wywołanie metody osobno.
2. Usługi sieciowe nie muszą utrzymywać poprzedniej interakcji klienta.
3. To z kolei upraszcza projektowanie aplikacji.
4. HTTP sam w sobie jest protokołem bezstanowym w przeciwieństwie do TCP, dlatego RESTful Web Services działa bezproblemowo z protokołami HTTP.

Wady bezpaństwowości:

1. Do każdego żądania należy dodać jedną dodatkową warstwę w postaci nagłówka, aby zachować stan klienta.
2. Dla bezpieczeństwa musimy dodać informacje nagłówka do każdego żądania.

Metody HTTP obsługiwane przez REST:

GET: / string / someotherstring Jest idempotentny i idealnie powinien zwracać te same wyniki przy każdym wywołaniu

PUT: Tak samo jak GET. Idempotent i służy do aktualizacji zasobów.

POST: powinien zawierać adres URL i treść używane do tworzenia zasobów. Wiele połączeń powinno idealnie zwracać różne wyniki i tworzyć wiele produktów.

USUŃ: Służy do usuwania zasobów na serwerze.

GŁOWA:

Metoda HEAD jest identyczna z GET, z tym wyjątkiem, że serwer NIE MOŻE zwracać treści komunikatu w odpowiedzi. Meta informacje zawarte w nagłówkach HTTP w odpowiedzi na żądanie HEAD MUSZĄ BYĆ identyczne z informacjami wysłanymi w odpowiedzi na żądanie GET.

OPCJE:

Ta metoda pozwala klientowi określić opcje i / lub wymagania związane z zasobem lub możliwości serwera, bez sugerowania akcji zasobu lub inicjowania pobierania zasobu.

Odpowiedzi HTTP

Przejdź tutaj, aby uzyskać wszystkie odpowiedzi .

Oto kilka ważnych: 200 - OK 3XX - Potrzebne są dodatkowe informacje od klienta i przekierowania adresu URL 400 - Błędne żądanie
401 - Brak dostępu do
403 - Zabronione
Żądanie było prawidłowe, ale serwer odmawia działania. Użytkownik może nie mieć niezbędnych uprawnień do zasobu lub może wymagać jakiegoś konta.

404 - Nie znaleziono
Żądany zasób nie został znaleziony, ale może być dostępny w przyszłości. Kolejne żądania klienta są dopuszczalne.

405 - Niedozwolona metoda Metoda żądania nie jest obsługiwana dla żądanego zasobu; na przykład żądanie GET w formularzu, które wymaga przedstawienia danych za pośrednictwem POST, lub żądanie PUT dla zasobu tylko do odczytu.

404 - Nie znaleziono żądania
500 - Błąd wewnętrznego serwera
502 - Błąd błędnej bramy

HTTP to protokół komunikacyjny, który przesyła wiadomości przez sieć. SOAP jest protokołem służącym do wymiany wiadomości opartych na XML, które mogą wykorzystywać HTTP do ich przesyłania. Reszta to protokół służący do wymiany dowolnych komunikatów (XML lub JSON), które mogą wykorzystywać HTTP do ich przesyłania.

HTTP is a contract, a communication protocol and REST is a concept, an architectural style które mogą wykorzystywać HTTP, FTP lub inne protokoły komunikacyjne, ale są szeroko stosowane z HTTP.

REST implies a series of constraints about how Server and Client should interact. HTTP is a communication protocol with a given mechanism for server-client data transfer, jest najczęściej używany w REST API tylko dlatego, że REST was inspired by WWW (world wide web) which largely used HTTPprzed zdefiniowaniem REST, więc łatwiej jest zaimplementować styl REST API z HTTP.

There are three major constraints in REST (but there are more):

1. Interakcje między serwerem a klientem powinny być opisywane wyłącznie za pomocą hipertekstu.

2.Serwer i klient powinny być luźno powiązane i nie poczynić żadnych wzajemnych założeń. Klient powinien znać tylko punkt wejścia zasobu. Dane dotyczące interakcji powinny zostać dostarczone przez serwer w odpowiedzi.

3.Serwer nie powinien przechowywać żadnych informacji o kontekście żądania. Żądania muszą być niezależne i idempotentne (oznacza to, że jeśli to samo żądanie jest powtarzane nieskończenie, pobierany jest dokładnie ten sam wynik)

A HTTP to tylko protokół komunikacyjny (narzędzie), który może pomóc w osiągnięciu tego celu.

Aby uzyskać więcej informacji, sprawdź te linki:

https://martinfowler.com/articles/richardsonMaturityModel.html http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

REST niekoniecznie jest związany z HTTP . Usługi sieciowe RESTful to tylko usługi sieciowe zgodne z architekturą RESTful.

What is Rest -
1- Client-server
2- Stateless
3- Cacheable
4- Layered system
5- Code on demand
6- Uniform interface

Od Nie znasz różnicy między HTTP a REST

Tak więc architektura REST i protokół HTTP 1.1 są od siebie niezależne, ale protokół HTTP 1.1 został zbudowany jako idealny protokół spełniający zasady i ograniczenia REST. Jednym ze sposobów spojrzenia na związek między HTTP a REST jest to, że REST to projekt, a HTTP 1.1 to implementacja tego projektu.

Interfejsy API REST muszą być sterowane hipertekstem

Z bloga Roya Fieldinga oto zestaw sposobów na sprawdzenie, czy budujesz API HTTP czy REST API:

Projektanci interfejsów API, zwróć uwagę na następujące zasady przed nazwaniem swojego interfejsu API REST:

• Interfejs API REST nie powinien być zależny od żadnego pojedynczego protokołu komunikacyjnego, chociaż jego pomyślne mapowanie na dany protokół może zależeć od dostępności metadanych, wyboru metod itp. Zasadniczo każdy element protokołu wykorzystujący URI do identyfikacji musi zezwalać każdy schemat identyfikatora URI, który należy zastosować w celu tej identyfikacji. [Błąd tutaj oznacza, że ​​identyfikacja nie jest oddzielona od interakcji.]
• Interfejs API REST nie powinien zawierać żadnych zmian w protokołach komunikacyjnych oprócz wypełnienia lub ustalenia szczegółów nieokreślonych bitów standardowych protokołów, takich jak metoda PATCH HTTP lub pole nagłówka łącza. Obejścia dla zepsutych implementacji (takich jak te przeglądarki, które są na tyle głupie, by wierzyć, że HTML definiuje zestaw metod HTTP) powinny być zdefiniowane osobno, a przynajmniej w dodatkach, z oczekiwaniem, że obejście to stanie się przestarzałe. [Niepowodzenie w tym przypadku oznacza, że ​​interfejsy zasobów są specyficzne dla obiektu, a nie ogólne.]
• Interfejs API REST powinien poświęcić prawie cały swój wysiłek opisowy na zdefiniowanie typów mediów używanych do reprezentowania zasobów i sterowania stanem aplikacji lub na definiowanie rozszerzonych nazw relacji i / lub znaczników z włączonym hipertekstem dla istniejących standardowych typów mediów. Wszelkie wysiłki włożone w opisanie metod, które należy zastosować w odniesieniu do interesujących URI, powinny być całkowicie zdefiniowane w ramach reguł przetwarzania dla typu nośnika (i, w większości przypadków, już zdefiniowane przez istniejące typy nośników). [Błąd tutaj oznacza, że ​​informacje pozapasmowe napędzają interakcję zamiast hipertekstu.]
• Interfejs API REST nie może definiować stałych nazw zasobów ani hierarchii (oczywiste połączenie klienta i serwera). Serwery muszą mieć swobodę kontrolowania własnej przestrzeni nazw. Zamiast tego pozwól serwerom instruować klientów, jak konstruować odpowiednie identyfikatory URI, na przykład w formularzach HTML i szablonach URI, poprzez zdefiniowanie tych instrukcji w typach multimediów i relacjach między linkami. [Niepowodzenie w tym przypadku oznacza, że ​​klienci przyjmują strukturę zasobów z powodu informacji pozapasmowych, takich jak specyficzny dla domeny standard, który jest zorientowanym na dane odpowiednikiem sprzężenia funkcjonalnego RPC].
• Interfejs API REST nigdy nie powinien mieć „wpisanych” zasobów, które są znaczące dla klienta. Autorzy specyfikacji mogą wykorzystywać typy zasobów do opisywania implementacji serwera za interfejsem, ale typy te muszą być nieistotne i niewidoczne dla klienta. Jedynymi typami istotnymi dla klienta są typ medialny bieżącej reprezentacji i znormalizowane nazwy relacji. [tak samo]
• Interfejs API REST należy wprowadzić bez wcześniejszej wiedzy poza początkowym identyfikatorem URI (zakładką) i zestawem standardowych typów mediów, które są odpowiednie dla docelowej grupy odbiorców (tj. Powinny być zrozumiałe dla każdego klienta, który mógłby korzystać z interfejsu API). Od tego momentu wszystkie przejścia stanu aplikacji muszą być sterowane przez wybór przez klienta wyborów dostarczonych przez serwer, które są obecne w otrzymanych reprezentacjach lub sugerowane przez manipulację tymi reprezentacjami przez użytkownika. Przejścia mogą być określane (lub ograniczane) przez wiedzę klienta na temat rodzajów mediów i mechanizmów komunikacji zasobów, które mogą być ulepszane w locie (np. Kod na żądanie). [Błąd tutaj oznacza, że ​​informacje pozapasmowe napędzają interakcję zamiast hipertekstu.]