Różnica między REST a CRUD

Nauczyłem się REST i bardzo przypomina CRUD (z tego, co przeczytałem o CRUD).

Wiem, że są różne i zastanawiam się, czy myślenie, że są podobne, oznacza, że ​​ich nie rozumiem.

Czy REST jest „nadzbiorem” CRUD? Czy wszystko, co robi CRUD i więcej?

Co zaskakujące, w innych odpowiedziach nie widzę, co uważam za prawdziwą różnicę między REST a CRUD: czym zarządza każdy.

CRUD oznacza podstawowe operacje do wykonania w repozytorium danych. Bezpośrednio obsługuje się rekordy lub obiekty danych; oprócz tych operacji rekordy są jednostkami pasywnymi. Zazwyczaj są to tylko tabele i rekordy bazy danych.

Z drugiej strony REST działa na reprezentacjach zasobów, z których każda jest identyfikowana przez adres URL. Zazwyczaj nie są to obiekty danych, ale złożone abstrakcje obiektów.

Na przykład zasób może być komentarzem użytkownika. Oznacza to nie tylko zapis w tabeli „komentarza”, ale także jego relacje z zasobem „użytkownika”, post, do którego komentarz jest dołączony, może inny komentarz, na który odpowiada.

Operowanie komentarzem nie jest prymitywną operacją bazy danych, może mieć znaczące skutki uboczne, takie jak ostrzeżenie oryginalnego plakatu lub ponowne obliczenie niektórych „punktów” podobnych do gry lub aktualizacja „strumienia obserwujących”.

Reprezentacja zasobów zawiera także hipertekst (sprawdź zasadę HATEOAS ), umożliwiając projektantowi wyrażenie relacji między zasobami lub prowadzenie klienta REST w przepływie pracy operacji.

W skrócie, CRUD to zestaw prymitywnych operacji (głównie dla baz danych i statycznych magazynów danych), podczas gdy REST jest bardzo wysokim poziomem API (głównie dla usług internetowych i innych systemów „na żywo”).

Pierwszy manipuluje podstawowymi danymi, drugi współdziała ze złożonym systemem.

Po pierwsze, oba są po prostu zwykłymi inicjałami; nie ma się czego bać.

Teraz CRUD to prosty termin, który został skrócony, ponieważ jest wspólną cechą wielu aplikacji i łatwiej jest powiedzieć CRUD . Opisuje 4 podstawowe operacje, które można wykonać na danych (lub zasobie). Twórz, czytaj, aktualizuj, usuwaj.

REST jest jednak nazwaną praktyką (podobnie jak AJAX), a nie technologią samą w sobie. Zachęca do korzystania z funkcji, które od dawna są związane z protokołem HTTP, ale rzadko są używane.

Gdy masz adres URL (Uniform Resource Locator ) i kierujesz na niego swoją przeglądarkę wierszem adresu, wysyłasz żądanie HTTP . Każde żądanie HTTP zawiera informacje, których serwer może użyć, aby dowiedzieć się, która odpowiedź HTTP odsyła do klienta, który wysłał żądanie.

Każde żądanie zawiera adres URL, dzięki czemu serwer wie, do którego zasobu chcesz uzyskać dostęp, ale może również zawierać metodę . Metoda opisuje, co zrobić z tym zasobem.

Ale ta koncepcja „metody” nie była używana zbyt często.

Zwykle ludzie po prostu prowadzą do stron za pomocą metody GET i wydają wszelkiego rodzaju aktualizacje (usuwanie, wstawianie, aktualizacje) za pomocą metody POST.

Z tego powodu nie można traktować jednego zasobu (URL) jako prawdziwego zasobu samego w sobie. Trzeba było mieć oddzielne adresy URL do usuwania, wstawiania lub aktualizacji tego samego zasobu. Na przykład:

http://...com/posts/create- POST request  -> Goes to posts.create() method in the server
http://...com/posts/1/show- GET request  -> Goes to posts.show(1) method in the server
http://...com/posts/1/delete - POST request  -> Goes to posts.delete(1) method in the server
http://...com/posts/1/edit- POST request  -> Goes to posts.edit(1) method in the server

Dzięki REST tworzysz formularze, które są mądrzejsze, ponieważ używają innych metod HTTP oprócz POST, i programujesz swój serwer tak, aby mógł rozróżniać metody , nie tylko adresy URL. Na przykład:

http://...com/posts - POST request  -> Goes to posts.create() method in the server
http://...com/posts/1 - GET request  -> Goes to posts.show(1) method in the server
http://...com/posts/1 - DELETE request  -> Goes to posts.delete(1) method in the server
http://...com/posts/1 - PUT request  -> Goes to posts.edit(1) method in the server

Pamiętaj, że pojedynczy adres URL opisuje pojedynczy zasób. Pojedynczy post jest pojedynczym zasobem. Dzięki REST traktujesz zasoby tak, jak powinny być traktowane. Mówisz serwerowi, który zasób chcesz obsłużyć i jak go obsłużyć.

Istnieje wiele innych funkcji „RESTful architecture”, o których możesz przeczytać w Wikipedii, innych artykułach lub książkach, jeśli jesteś zainteresowany. Z drugiej strony sama CRUD nie ma wiele więcej.

REST oznacza „reprezentacyjny transfer stanu”, co oznacza, że ​​chodzi o komunikację i modyfikację stanu niektórych zasobów w systemie.

REST bardzo się angażuje, ponieważ teoria REST wprowadza media, hipermedia i podstawowy protokół do zarządzania informacjami w systemie zdalnym.

Z drugiej strony CRUD jest mnemonikiem typowych operacji potrzebnych dla danych w bazie danych: Utwórz Pobierz Aktualizuj Usuń. Ale tak naprawdę to nie jest głębsze.

To jest odpowiedź na twoje pytanie, ale wspomnę o powszechnym błędzie, jaki widzę, gdy REST i CRUD są omawiane razem. Wielu programistów chce bezpośrednio mapować REST na CRUD, ponieważ REST przez HTTP zapewnia GET PUT POST i DELETE, podczas gdy CRUD zapewnia CREATE RETRIEVE UPDATE DELETE. Naturalne jest, że chcesz mapować czasowniki REST bezpośrednio na operacje CRUD.

Jednak HTTP używa stylu „utwórz lub zaktualizuj”, podczas gdy CRUD rozdziela tworzenie i aktualizację. To uniemożliwia (!) Stworzenie czystego, ogólnego mapowania między nimi (!)

GET i DELETE są łatwe ... GET === RETRIEVE, a DELETE === DELETE.

Ale zgodnie ze specyfikacją HTTP PUT to tak naprawdę Utwórz ORAZ Zaktualizuj:

• Użyj PUT, aby utworzyć zupełnie nowy obiekt, gdy wiesz o nim wszystko, w tym jego identyfikator

• Użyj PUT, aby zaktualizować obiekt (zwykle z pełną reprezentacją obiektu)

POST jest czasownikiem „przetwarzającym” i jest uważany za czasownik „dołączający”:

• Użyj POST, aby dołączyć nowy obiekt do kolekcji - czyli utwórz nowy obiekt

• POST jest również używany, gdy żaden z pozostałych czasowników nie jest w pełni dopasowany, ponieważ specyfikacja HTTP definiuje go jako czasownik „przetwarzania danych”

• Jeśli Twój zespół rozłącza się na POST, pamiętaj, że cała WWW została zbudowana na GET i POST;)

Tak więc chociaż istnieje podobieństwo między REST i CRUD, błędem, który widzę, że większość zespołów popełnia, jest wyrównanie między nimi. Zespół naprawdę musi zachować ostrożność podczas definiowania interfejsu API REST, aby nie rozwiewać się zbytnio na mnemonice CRUD, ponieważ REST jako praktyka ma naprawdę wiele dodatkowych złożoności, które nie mapują się czysto na CRUD.

CRUD określa minimalny zestaw podstawowych czasowników pamięci do odczytu i zapisu danych: tworzenie, czytanie, aktualizacja i usuwanie. Następnie możesz budować inne operacje, agregując je. Są to zwykle operacje bazy danych, ale to, co uważa się za bazę danych, jest arbitralne (np. Może to być relacyjny DBMS, ale może to być również pliki YAML).

REST jest „stylem architektonicznym”, który zwykle obejmuje operacje CRUD i inne operacje wyższego poziomu, wszystkie do wykonania na pewnej koncepcji „zasobów” (dowolne, ale są to byty w twojej aplikacji). REST ma wiele ograniczeń, które sprawiają, że jest interesujący (a szczególnie dobrze sparowany z HTTP).

Interfejs REST może, ale nie musi, ujawniać wszystkie operacje CRUD dla określonego zasobu. To, co jest dostępne w interfejsie REST, jest arbitralne i może ulec zmianie ze względu na uprawnienia systemowe, uwagi dotyczące interfejsu użytkownika oraz to, jak gorąco było w dniu zaprojektowania i utworzenia interfejsu. Zwykle cieplejsze dni prowadzą do bardziej minimalistycznych interfejsów, choć może być odwrotnie.

CRUD

• CRUD to cztery podstawowe typy poleceń SQL: Utwórz, Odczytaj, Aktualizuj i Usuń
• Większość aplikacji ma jakąś funkcjonalność CRUD
• Aplikacja CRUD to taka, która używa formularzy do pobierania danych z bazy danych i do niej

ODPOCZYNEK

• REST to skrót od Representative State Transfer (czasami jest napisane „ReST”)

• Opiera się na bezstanowym protokole komunikacyjnym klient-serwer, który może być buforowany - i praktycznie we wszystkich przypadkach używany jest protokół HTTP

• REST to styl architektury do projektowania aplikacji sieciowych

REST jest czymś w rodzaju strony internetowej dla maszyn, którą mogą przeglądać, podczas gdy CRUD jest czymś w rodzaju SOAP, który jest silnie powiązany z klientami. To są główne różnice. Ofc. na powierzchni są podobne, ale CRUD opisuje podstawową manipulację bytem, ​​natomiast REST może opisywać interfejs dowolnej aplikacji. Kolejna różnica polegająca na tym, że REST może wykorzystywać więcej 4 metod HTTP. Byłaby to bardzo długa odpowiedź, jeśli chciałbym zebrać wszystkie różnice, jeśli sprawdzisz pytania dotyczące REST vs SOAP, znajdziesz większość z nich.

Myślę, że mylenie REST z CRUD jest bardzo częstym błędem, a przyczyną jest to, że programiści nie mają czasu na szczegółowe czytanie o REST. Chcą tylko korzystać z technologii - bez jej zrozumienia - w oparciu o ograniczone przykłady stylu CRUD napisane przez podobnych programistów. Zdecydowana większość przykładów i samouczków odzwierciedla poważny brak wiedzy. Mapowanie zasobów REST do encji i metod HTTP do operacji CRUD tych encji i używanie REST bez hiperłączy jest tylko tego objawem. Przez REST mapujesz hiperłącza (w tym linki metodami POST / PUT / DELETE / PATCH) do swoich operacji i identyfikujesz operację po stronie klienta, sprawdzając relację linków (zwykle API). Jeśli klient REST nie wie, czym jest relacja łącza, i zna tylko metody HTTP i być może niektóre szablony URI, to nie jest klient REST, ale CRUD na kliencie HTTP. Innym częstym błędem polegającym na tym, że klient REST jest jednostronicową aplikacją javascript działającą w przeglądarce. Oczywiście możesz wdrożyć takiego klienta, ale REST był przeznaczony głównie dla klientów automatycznych (aplikacje po stronie serwera napisane przez programistów, których nawet nie znasz), a nie dla klientów ręcznych (napisane przez ciebie aplikacje przeglądarki). Posiadanie tylko jednego klienta przeglądarki może być oznaką, że tak naprawdę nie potrzebujesz REST, a po prostu przeprojektowałeś projekt. W takich przypadkach interfejs API CRUD jest realnym rozwiązaniem, a programiści nazywają te interfejsy CRUD API jako REST, ponieważ nie znają różnicy. Oczywiście możesz wdrożyć takiego klienta, ale REST był przeznaczony głównie dla klientów automatycznych (aplikacje po stronie serwera napisane przez programistów, których nawet nie znasz), a nie dla klientów ręcznych (napisane przez ciebie aplikacje przeglądarki). Posiadanie tylko jednego klienta przeglądarki może być oznaką, że tak naprawdę nie potrzebujesz REST, a po prostu przeprojektowałeś projekt. W takich przypadkach interfejs API CRUD jest realnym rozwiązaniem, a programiści nazywają te interfejsy CRUD API jako REST, ponieważ nie znają różnicy. Oczywiście możesz wdrożyć takiego klienta, ale REST był przeznaczony głównie dla klientów automatycznych (aplikacje po stronie serwera napisane przez programistów, których nawet nie znasz), a nie dla klientów ręcznych (napisane przez ciebie aplikacje przeglądarki). Posiadanie tylko jednego klienta przeglądarki może być oznaką, że tak naprawdę nie potrzebujesz REST, a po prostu przeprojektowałeś projekt. W takich przypadkach interfejs API CRUD jest realnym rozwiązaniem, a programiści nazywają te interfejsy CRUD API jako REST, ponieważ nie znają różnicy.