Mam serwis WWW, który akceptuje parametry JSON i ma określone adresy URL dla metod, np .:
http://IP:PORT/API/getAllData?p={JSON}
To zdecydowanie nie jest REST, ponieważ nie jest to stan bezpaństwowy. Uwzględnia pliki cookie i ma własną sesję.
Czy to RPC? Jaka jest różnica między RPC a REST?
Odpowiedzi:
Nie można dokonać wyraźnego oddzielenia REST od RPC, patrząc tylko na to, co opublikowałeś.
Jednym z ograniczeń REST jest to, że musi być bezpaństwowy. Jeśli masz sesję, masz stan, więc nie możesz wywołać usługi RESTful.
Fakt, że masz akcję w swoim adresie URL (tj. getAllData), Wskazuje na RPC. W REST wymieniasz reprezentacje, a wykonywana operacja jest podyktowana zleceniami HTTP. Ponadto w REST negocjacja zawartości nie jest wykonywana z ?p={JSON}parametrem.
Nie wiem, czy twoja usługa to RPC, ale nie jest RESTful. Możesz dowiedzieć się o różnicy online, oto artykuł na początek: Obalanie mitów RPC i REST . Wiesz lepiej, co jest w Twojej usłudze, więc porównaj jej funkcje z tym, czym jest RPC i wyciągnij własne wnioski.
Rozważmy następujący przykład interfejsów API HTTP, które modelują zamówienia składane w restauracji.
Składając zamówienie:
Pobieranie zamówienia:
Aktualizacja zamówienia:
Przykład pobrany z sites.google.com/site/wagingguerillasoftware/rest-series/what-is-restful-rest-vs-rpc
Jak powiedzieli inni, kluczową różnicą jest to, że REST koncentruje się na rzeczownikach, a RPC na czasownikach. Chciałem tylko zamieścić tę przejrzystą tabelę przykładów pokazujących, że:
--------------------------- + ---------------------- --------------- + -------------------------- Obsługa | RPC (operacja) |REST (zasób) --------------------------- + ---------------------- --------------- + -------------------------- Zarejestruj się | POST / rejestracja | POCZTA / osoby --------------------------- + ---------------------- --------------- + -------------------------- Rezygnuj | POST / zrezygnuj | USUŃ / osoby / 1234 --------------------------- + ---------------------- --------------- + -------------------------- Przeczytaj osobę | GET / readPerson? Personid = 1234 | POBIERZ / osoby / 1234 --------------------------- + ---------------------- --------------- + -------------------------- Przeczytaj listę przedmiotów osoby | GET / readUsersItemsList? Userid = 1234 | POBIERZ / osoby / 1234 / szt --------------------------- + ---------------------- --------------- + -------------------------- Dodaj pozycję do listy osoby | POST / addItemToUsersItemsList | POCZTA / osoby / 1234 / poz --------------------------- + ---------------------- --------------- + -------------------------- Zaktualizuj element | POST / modyfikujItem | PUT / szt./ 456 --------------------------- + ---------------------- --------------- + -------------------------- Usuń przedmiot | POST / removeItem? ItemId = 456 | USUŃ / pozycje / 456 --------------------------- + ---------------------- --------------- + --------------------------
Uwagi
GET /persons/1234), Podczas gdy RPC ma tendencję do używania parametrów zapytań do wprowadzania funkcji GET /readPerson?personid=1234.).GET /persons?height=tall.).POST /signuplub POST /persons, gdy dołączasz dane opisujące nową osobę).Jest to RPC używające protokołu http . Prawidłowa implementacja REST powinna różnić się od RPC. Posiadanie logiki przetwarzania danych, takiej jak metoda / funkcja, to RPC. getAllData () to inteligentna metoda. REST nie może mieć inteligencji, powinien to być zrzut danych, które mogą być odpytywane przez zewnętrzną inteligencję .
Większość implementacji, które widziałem w dzisiejszych czasach, to RPC, ale wielu błędnie nazywa to REST. REST z HTTP jest wybawcą, a SOAP z XML-em złoczyńcą. Więc twoje zamieszanie jest uzasadnione i masz rację, to nie jest REST.
Protokół HTTP nie wykonuje implementacji REST. Zarówno REST (GET, POST, PUT, PATCH, DELETE), jak i RPC (GET + POST) mogą być tworzone przez HTTP (np. Poprzez projekt internetowego API w Visual Studio).
Dobrze, ale czym jest w takim razie REST? Model dojrzałości Richardsona podano poniżej (podsumowanie). Tylko poziom 3 jest RESTful.
np .: poziom 3 (HATEOAS):
Link stwierdza, że ten obiekt może być aktualizowany w ten sposób i dodawany w ten sposób.
Link stwierdza, że ten obiekt można tylko odczytać i tak to robimy.
Oczywiście, wysyłanie danych nie wystarczy, aby stać się REST, ale należy również wspomnieć o tym, jak przeszukiwać dane. Ale z drugiej strony, dlaczego 4 kroki? Dlaczego nie może to być po prostu Krok 4 i nazwać go REST? Richardson właśnie przedstawił nam krok po kroku, jak się tam dostać, to wszystko.
Stworzyłeś witryny internetowe, z których mogą korzystać ludzie. Ale czy możesz także tworzyć witryny internetowe, z których mogą korzystać komputery? To jest przyszłość, a usługi RESTful Web Services pokazują, jak to zrobić.
PS: REST jest bardzo popularny, podobnie jak testy automatyczne, ale jeśli chodzi o przykłady ze świata rzeczywistego… cóż…
REST najlepiej opisać do pracy z zasobami, podczas gdy RPC bardziej dotyczy działań.
REST oznacza Representational State Transfer. Jest to prosty sposób organizowania interakcji między niezależnymi systemami. Aplikacje RESTful często 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 może używać protokołu HTTP dla wszystkich czterech operacji CRUD (tworzenie / odczytywanie / aktualizowanie / usuwanie).
RPC jest zasadniczo używany do komunikacji między różnymi modułami w celu obsługi żądań użytkowników. np. w OpenStack, jak na przykład, jak nova, glance i neutron współpracują ze sobą podczas uruchamiania maszyny wirtualnej.
W ten sposób argumentowałbym:
Czy mój podmiot posiada / jest właścicielem danych? Następnie RPC: oto kopia niektórych moich danych, manipuluj kopią danych, którą do Ciebie wysyłam i zwróć mi kopię swojego wyniku.
Czy wezwany podmiot posiada / jest właścicielem danych? Następnie REST: albo (1) pokaż mi kopię niektórych swoich danych, albo (2) manipuluj niektórymi danymi.
Ostatecznie chodzi o to, która „strona” działania jest właścicielem / posiada dane. I tak, możesz używać słownictwa REST do komunikacji z systemem opartym na RPC, ale nadal będziesz wykonywać czynności RPC.
Przykład 1: Mam obiekt, który komunikuje się z magazynem relacyjnej bazy danych (lub innym typem magazynu danych) za pośrednictwem DAO. Sensowne jest używanie stylu REST do interakcji między moim obiektem a obiektem dostępu do danych, który może istnieć jako API. Moja jednostka nie posiada / nie posiada danych, tak jak relacyjna baza danych (lub nierelacyjny magazyn danych).
Przykład 2: Muszę zrobić dużo skomplikowanej matematyki. Nie chcę ładować wielu metod matematycznych do mojego obiektu, po prostu chcę przekazać pewne wartości do czegoś innego, co może wykonać wszystkie rodzaje matematyki, i uzyskać wynik. Wtedy styl RPC ma sens, ponieważ obiekt / jednostka matematyczna ujawni mojemu obiektowi całą masę operacji. Zwróć uwagę, że wszystkie te metody mogą być ujawnione jako indywidualne interfejsy API i mogę wywołać dowolne z nich za pomocą GET. Mogę nawet twierdzić, że jest to RESTful, ponieważ dzwonię przez HTTP GET, ale tak naprawdę pod osłonami jest to RPC. Mój podmiot jest właścicielem / przechowuje dane, podmiot zdalny po prostu dokonuje manipulacji na kopiach danych, które do niego wysłałem.
Jest tutaj kilka dobrych odpowiedzi. Nadal bym cię do tego odesłał bloga Google, ponieważ bardzo dobrze omawia różnice między RPC i REST i zawiera coś, czego nie przeczytałem w żadnej z odpowiedzi tutaj.
Zacytowałbym akapit z tego samego linku, który mnie wyróżniał:
Sam REST jest opisem zasad projektowania, które stanowią podstawę HTTP i sieci WWW. Ale ponieważ HTTP jest jedynym komercyjnie ważnym interfejsem API REST, możemy w większości uniknąć dyskusji o REST i po prostu skupić się na HTTP. To podstawienie jest przydatne, ponieważ istnieje wiele nieporozumień i różnorodności w tym, co ludzie myślą, że REST oznacza w kontekście interfejsów API, ale istnieje znacznie większa jasność i zgodność co do tego, czym jest sam HTTP. Model HTTP jest idealną odwrotnością modelu RPC - w modelu RPC adresowalne jednostki są procedurami, a jednostki domeny problemowej są ukryte za procedurami. W modelu HTTP jednostkami adresowalnymi są same encje, a zachowania systemu są ukryte za encjami jako skutki uboczne ich tworzenia, aktualizowania lub usuwania.
Oto jak je rozumiem i używam w różnych przypadkach użycia:
Przykład: Zarządzanie restauracją
przypadek użycia dla REST : zarządzanie zamówieniami
- create order (POST), update order (PATCH), cancel order (DELETE), retrieve order (GET)
- endpoint: /order?orderId=123
W przypadku zarządzania zasobami REST jest czysty. Jeden punkt końcowy ze wstępnie zdefiniowanymi akcjami. Można go postrzegać jako sposób ujawnienia DB (Sql lub NoSql) lub instancji klas światu.
Przykład implementacji:
class order:
on_get(self, req, resp): doThis.
on_patch(self, req, resp): doThat.
Przykład struktury: Falcon dla Pythona.
przypadek użycia RPC : zarządzanie operacjami
- prepare ingredients: /operation/clean/kitchen
- cook the order: /operation/cook/123
- serve the order /operation/serve/123
W przypadku stanowisk analitycznych, operacyjnych, niereagujących, niereprezentatywnych i opartych na działaniu RPC działa lepiej i myślenie funkcjonalne jest bardzo naturalne.
Przykład implementacji:
@route('/operation/cook/<orderId>')
def cook(orderId): doThis.
@route('/operation/serve/<orderId>')
def serve(orderId): doThat.
Przykład struktury: Flask dla Pythona