Przeczytałem kilka definicji i dyskusji na temat REST i / lub RESTful aplikacji, ale nadal nie rozumiem prawdziwego znaczenia tego.
Zwykle pracuję z aplikacjami, które albo pobierają dane przez GET, albo wysyłają dane przez POST do jakiegoś serwisu internetowego (zwykle skryptu PHP), który następnie albo pobiera dane z bazy danych, albo zapisuje dane w bazie danych.
Czy to jest aplikacja RESTful? Jeśli nie, jaka byłaby aplikacja RESTful? Jaka jest różnica między koncepcją RESTful a koncepcją, z którą do tej pory pracowałem? Proszę wyjaśnić na przykładzie.
Ponadto ktoś mówi o REST, a ktoś o RESTful aplikacjach. Odkryłem, że termin REST odnosi się do koncepcji teoretycznej, natomiast RESTful jest używany, gdy mówimy o konkretnej aplikacji. Czy to prawda, czy istnieją prawdziwe różnice między aplikacjami REST i RESTful?
Odpowiedzi:
Kluczowymi atrybutami aplikacji RESTful są: Cała komunikacja odbywa się za pośrednictwem protokołu HTTP GET, POST, PUT, DELETE I wszystkie elementy są adresowane za pomocą standardowego adresu URL formularza,
http://your.site.com/salesapp/salesperson/0000001/detailstj. Tylko czysty adres URL bez parametrów itp. URL identyfikuje element GET , POST, PUT, DELETE określa, co chcesz z tym zrobić.Głównym powodem tego jest to, że automatycznie masz usługę bezstanową, która może być równoważona obciążeniem, przełączaniem awaryjnym itp. Itp.
Sama prostota schematu sprawia, że interfejs jest bardzo czysty, całkowicie oddzielając klienta od konkretnej implementacji zaplecza.
źródło
REST to skrót od Representative State Transfer. Jeśli oprogramowanie jest zgodne z ograniczeniami REST, wówczas uznaje się je za RESTful.
Tak, teraz, kiedy bezwstydnie zgrałem z Wikipedii, co to tak naprawdę oznacza? Skutecznie oznacza to użycie wbudowanych poleceń HTTP, takich jak GET, POST, PUT, DELETE i kilka innych rzadszych, do komunikacji między klientem a serwerem.
To, co robisz, brzmi jak aplikacja RESTFul. Istnieje jednak duża różnica między dobrze zaprojektowanymi i stosami śmieciowych usług internetowych RESTFul. Na przykład kod PHP na drugim końcu GET może wykonać zmianę stanu, co byłoby uważane za nieprawidłowe, ponieważ GET jest postrzegany jako operacja tylko do odczytu. Istnieją również subtelne różnice między sposobem użycia POST (nowy) i PUT (zamień).
Artykuł w Wikipedii na ten temat jest naprawdę bardzo dobry, więc zatrzymam się tutaj.
źródło
Zanim przejdziemy dalej, to powiązane pytanie może ci pomóc
Różnica między REST i RESTful to po prostu semantyka. REST to styl architektoniczny stosowany do relacji klient-serwer. RESTful to po prostu sposób na poinformowanie klientów, że korzystasz z REST.
Wiele aplikacji internetowych twierdzi, że jest RESTful, ale w rzeczywistości są one tylko częściowo zgodne z ograniczeniami REST (jak Martijn Verburg również wspomniał w swojej odpowiedzi). Wymienię je tutaj, ale gorąco zachęcam do przeczytania artykułu:
Ponieważ wspominasz, że pracujesz po stronie klienta, pomocne może być sprawdzenie, co daje architektura REST i czego można oczekiwać od ciebie jako klienta łączącego się. Mimo że REST nie jest HTTP, jest to zdecydowanie najpopularniejszy protokół, który obsługuje REST, dlatego opowiem o nim mój przykład.
Twój klient będzie musiał:
<link rel="pay" href="http://example.org/orders(1)/payment">w HTML wyraża przejście stanu w celu utworzenia zasobu płatniczego za pomocą POST z treścią zawierającą XML, który reprezentuje szczegóły płatności, takie jak numer karty kredytowej , kwota i tak dalej)Jeśli spełnia powyższe warunki, można uznać, że jest to klient REST, możesz nazwać go „aplikacją RESTful”, ale to raczej sugeruje, że używasz REST po stronie klienta, co jest niepoprawne, dlatego najlepiej go unikać termin.
źródło
RESTful oznacza, że interfejs jest zestawem obiektów, które można czytać i aktualizować (i ewentualnie usuwać). Oznacza to, że nie ma zapytań wieloparametrowych (tylko parametr jest obiektem, który chcesz przeczytać) i istnieje tylko jeden rodzaj operacji, który zmienia cokolwiek na serwerze, przesyłanie nowego stanu.
Ograniczenia te zapewniają, że wszystkie żądania są idempotentne (wielokrotne wysyłanie ich nie ma żadnego dodatkowego wpływu na wysyłanie ich raz). Jest to ważne, ponieważ sieć może ulec awarii w dowolnym momencie i nie dostarczyć żadnego żądania ani odpowiedzi, a przy idempotentnych żądaniach wystarczy wysłać ją ponownie i nie trzeba wykonywać skomplikowanego odzyskiwania.
źródło