Czym dokładnie jest programowanie RESTful?
http
rest
definition
hasen
źródło
źródło
Odpowiedzi:
Styl architektoniczny zwany REST (representational state transfer) opowiada, że aplikacje internetowe powinny używać HTTP jak to było pierwotnie przewidywał . Wyszukiwanie powinno wykorzystywać
GET
żądania.PUT
,POST
iDELETE
żądania należy wykorzystywać odpowiednio do mutacji, tworzenia i usuwania .Zwolennicy REST preferują adresy URL, takie jak
ale architektura REST nie wymaga tych „ładnych adresów URL”. Żądanie GET z parametrem
jest tak samo jak RESTful.
Należy pamiętać, że żądania GET nigdy nie powinny być wykorzystywane do aktualizacji informacji. Na przykład żądanie GET dotyczące dodania elementu do koszyka
nie byłoby właściwe. Żądania GET powinny być idempotentne . Oznacza to, że dwukrotne wysłanie żądania nie powinno różnić się od wysłania go raz. To sprawia, że żądania są buforowalne. Żądanie „dodaj do koszyka” nie jest idempotentne - dwukrotne wysłanie powoduje dodanie dwóch kopii produktu do koszyka. W tym kontekście żądanie POST jest wyraźnie właściwe. Dlatego nawet aplikacja internetowa RESTful potrzebuje swojej części żądań POST.
To pochodzi z doskonałej książki Davida M. Geary'ego „ Core JavaServer Faces ”.
źródło
REST jest podstawową zasadą architektury sieci. Niesamowitą rzeczą w Internecie jest fakt, że klienci (przeglądarki) i serwery mogą wchodzić w interakcje w skomplikowany sposób, bez uprzedniej wiedzy o serwerze i zasobach, które hostuje. Kluczowym ograniczeniem jest to, że zarówno serwer, jak i klient muszą się zgodzić na użyte media , którymi w przypadku Internetu jest HTML .
Interfejs API zgodny z zasadami REST nie wymaga od klienta wiedzy na temat struktury interfejsu API. Zamiast tego serwer musi podać wszelkie informacje potrzebne klientowi do interakcji z usługą. Przykładem jest formularz HTML : Serwer określa lokalizację zasobu i wymagane pola. Przeglądarka nie wie z góry, gdzie przesłać informacje, i nie wie z góry, jakie informacje przesłać. Obie formy informacji są w całości dostarczane przez serwer. (Ta zasada nazywa się HATEOAS : Hypermedia As The Engine Of Application State ).
Jak to się ma do HTTP i jak można to zaimplementować w praktyce? HTTP jest zorientowany na czasowniki i zasoby. Dwoma czasownikami używanymi w głównym nurcie są
GET
iPOST
, myślę, że wszyscy je rozpoznają. Jednak standard HTTP definiuje kilka innych, takich jakPUT
iDELETE
. Czasowniki te są następnie stosowane do zasobów, zgodnie z instrukcjami dostarczonymi przez serwer.Wyobraźmy sobie na przykład, że mamy bazę danych użytkowników zarządzaną przez usługę internetową. Nasza usługa korzysta z niestandardowej hipermedii opartej na JSON, do której przypisujemy typ mimetyczny
application/json+userdb
(może istniećapplication/xml+userdb
iapplication/whatever+userdb
- może być obsługiwanych wiele typów mediów). Zarówno klient, jak i serwer zostały zaprogramowane do zrozumienia tego formatu, ale nic o sobie nie wiedzą. Jak zauważa Roy Fielding :Żądanie zasobu podstawowego
/
może zwrócić coś takiego:Żądanie
Odpowiedź
Z opisu naszych mediów wiemy, że informacje o pokrewnych zasobach możemy znaleźć w sekcjach zwanych „linkami”. Nazywa się to kontrolkami Hypermedia . W takim przypadku możemy stwierdzić z takiej sekcji, że możemy znaleźć listę użytkowników, wysyłając kolejne żądanie
/user
:Żądanie
Odpowiedź
Z tej odpowiedzi możemy wiele powiedzieć. Na przykład, teraz wiemy, możemy utworzyć nowego użytkownika przez
POST
ING/user
:Żądanie
Odpowiedź
Wiemy również, że możemy zmienić istniejące dane:
Żądanie
Odpowiedź
Zauważ, że używamy różnych zleceń HTTP (
GET
,PUT
,POST
,DELETE
itd.), Aby manipulować tych zasobów, i że tylko wiedza zakładamy ze strony klienta jest nasza definicja mediów.Dalsza lektura:
Jak wyjaśniłem REST mojej żonie .(Ta odpowiedź była przedmiotem dużej krytyki za pominięcie tego. W większości była to uczciwa krytyka. To, co pierwotnie opisałem, było bardziej zgodne z tym, jak REST był zwykle wdrażany kilka lat temu, kiedy ja najpierw napisałem to, a nie jego prawdziwe znaczenie. Poprawiłem odpowiedź, aby lepiej reprezentować prawdziwe znaczenie).
źródło
Programowanie RESTful polega na:
Create
,Retrieve
,Update
,Delete
stajePOST
,GET
,PUT
, iDELETE
. Ale REST nie ogranicza się do HTTP, jest to obecnie najczęściej używany transport.Ten ostatni jest prawdopodobnie najważniejszy pod względem konsekwencji i ogólnej skuteczności REST. Ogólnie rzecz biorąc, większość dyskusji RESTful wydaje się koncentrować na HTTP i jego wykorzystaniu z przeglądarki, a co nie. Rozumiem, że R. Fielding ukuł ten termin, opisując architekturę i decyzje prowadzące do HTTP. Jego praca dyplomowa dotyczy bardziej architektury i zdolności buforowania zasobów niż HTTP.
Jeśli naprawdę interesuje Cię, czym jest architektura RESTful i dlaczego działa, przeczytaj kilkakrotnie jego pracę magisterską i przeczytaj całość, nie tylko rozdział 5! Następnie sprawdź, dlaczego DNS działa . Przeczytaj o hierarchicznej organizacji DNS i o tym, jak działają odwołania. Następnie przeczytaj i zastanów się, jak działa buforowanie DNS. Na koniec przeczytaj specyfikacje HTTP ( w szczególności RFC2616 i RFC3040 ) i zastanów się, jak i dlaczego buforowanie działa w ten sposób. W końcu po prostu kliknie. Ostateczne objawienie było dla mnie, gdy zobaczyłem podobieństwo między DNS a HTTP. Po tym zrozumienie, dlaczego SOA i interfejsy przekazywania wiadomości są skalowalne, zaczyna klikać.
Myślę, że najważniejszą sztuczką dla zrozumienia znaczenia architektonicznego i wpływu na wydajność architektury RESTful i Shared Nothing jest unikanie rozłączania się z technologią i szczegółami implementacji. Skoncentruj się na tym, kto jest właścicielem zasobów, kto jest odpowiedzialny za ich tworzenie / utrzymanie itp. Następnie pomyśl o reprezentacjach, protokołach i technologiach.
źródło
PUT
iPOST
nie mapuj jeden na jeden za pomocą aktualizacji i tworzenia.PUT
można go użyć do utworzenia, jeśli klient decyduje o tym, jaki będzie identyfikator URI.POST
tworzy, jeśli serwer przypisuje nowy identyfikator URI.urn:
schematu. Koncepcyjnie nie ma różnicy; jednak URN wymaga posiadania osobno zdefiniowanej metody „lokalizowania” zasobu zidentyfikowanego (nazwanego) przez URN. Należy zadbać o to, aby nie wprowadzać niejawnego łączenia w przypadku nazwanych zasobów i ich lokalizacji.Tak może to wyglądać.
Utwórz użytkownika z trzema właściwościami:
Serwer odpowiada:
W przyszłości możesz pobrać informacje o użytkowniku:
Serwer odpowiada:
Aby zmodyfikować rekord (
lname
iage
pozostanie niezmieniony):Aby zaktualizować rekord (aw konsekwencji
lname
iage
będzie NULL):źródło
PUT fname=Jonny
. To ustawienielname
iage
do wartości domyślnych (prawdopodobnie null lub pusty ciąg znaków, a całkowite 0), ponieważPUT
nadpisuje cały zasób danymi z reprezentacją usług. Nie jest to sugerowane przez „aktualizację”. Aby wykonać prawdziwą aktualizację, użyjPATCH
metody, ponieważ nie zmienia to pól, które nie są określone w reprezentacji./user/1
nie ma sensu i powinien istnieć wpis na/users
. W takim przypadku odpowiedź powinna być „a”201 Created
i „OK”.Świetną książką na temat REST jest REST w praktyce .
Wymagane odczyty to REST (Representational State Transfer), a interfejsy API REST muszą obsługiwać hipertekst
Zobacz artykuł Martina Fowlersa o modelu dojrzałości Richardsona (RMM), aby uzyskać wyjaśnienie, czym jest usługa RESTful.
Aby uzyskać RESTful, usługa musi spełniać Hypermedia jako silnik stanu aplikacji. (HATEOAS) , czyli musi osiągnąć poziom 3 w RMM, przeczytaj artykuł, aby uzyskać szczegółowe informacje lub slajdy z rozmowy qcon .
Test REST Litmus dla frameworków internetowych jest podobnym testem dojrzałości dla frameworków internetowych.
Zbliża się czysty REST: Nauka kochania HATEOAS to dobry zbiór linków.
REST a SOAP dla chmury publicznej omawia bieżące poziomy wykorzystania REST.
REST i wersjonowanie omawiają rozszerzalność, wersjonowanie, ewoluowalność itp. Poprzez modyfikację
źródło
Jedno z najlepszych odniesień, jakie znalazłem, gdy próbowałem znaleźć proste prawdziwe znaczenie odpoczynku.
http://rest.elkstein.org/
źródło
REST używa różnych metod HTTP (głównie GET / PUT / DELETE) do manipulowania danymi.
Zamiast używać określonego adresu URL do usunięcia metody (powiedzmy
/user/123/delete
), wysłałbyś żądanie DELETE na/user/[id]
adres URL, aby edytować użytkownika, aby uzyskać informacje o użytkowniku, do którego wysyłasz zapytanie GET/user/[id]
Na przykład zamiast zestawu adresów URL, które mogą wyglądać następująco:
Używasz „czasowników” HTTP i masz ...
źródło
To programowanie, w którym architektura twojego systemu pasuje do stylu REST przedstawionego przez Roy'a Fieldinga w jego pracy dyplomowej . Ponieważ jest to styl architektoniczny opisujący sieć (mniej więcej), wiele osób jest nią zainteresowanych.
Dodatkowa odpowiedź: Nie. Jeśli nie studiujesz architektury oprogramowania jako akademickiej lub projektujesz usługi sieciowe, naprawdę nie ma powodu, aby słyszeć ten termin.
źródło
Powiedziałbym, że programowanie RESTful polegałoby na tworzeniu systemów (API) zgodnych ze stylem architektonicznym REST.
Znalazłem ten fantastyczny, krótki i łatwy do zrozumienia samouczek na temat REST autorstwa dr M. Elksteina i cytuję zasadniczą część, która w większości odpowiedziałaby na twoje pytanie:
Dowiedz się REST: samouczek
Nie sądzę, że powinieneś czuć się głupio, że nie słyszałeś o REST poza przepełnieniem stosu ... Byłbym w tej samej sytuacji !; odpowiedzi na to inne SO pytanie w sprawie Dlaczego REST robi się duży, może złagodzić niektóre uczucia.
źródło
Przepraszam, jeśli nie odpowiadam bezpośrednio na pytanie, ale łatwiej jest to wszystko zrozumieć za pomocą bardziej szczegółowych przykładów. Fielding nie jest łatwy do zrozumienia ze względu na całą abstrakcję i terminologię.
Jest tu całkiem dobry przykład:
Wyjaśnienie REST i hipertekstu: Spam-E robot do czyszczenia spamu
Co więcej, tutaj jest jasne wyjaśnienie z prostymi przykładami (PowerPoint jest bardziej wyczerpujący, ale większość można uzyskać w wersji HTML):
http://www.xfront.com/REST.ppt lub http://www.xfront.com/REST.html
Po przeczytaniu przykładów zrozumiałem, dlaczego Ken twierdzi, że REST jest sterowany hipertekstem. Nie jestem jednak pewien, czy ma rację, ponieważ ten / user / 123 jest identyfikatorem URI, który wskazuje na zasób, i nie jest dla mnie jasne, że jest on RESZTOWY tylko dlatego, że klient wie o tym „poza pasmem”.
Ten dokument xfront wyjaśnia różnicę między REST a SOAP, i to też jest naprawdę pomocne. Kiedy Fielding mówi: „ To jest RPC. To krzyczy RPC. ”, Jasne jest, że RPC nie jest ODPOCZYNEK, więc warto zobaczyć dokładne powody. (SOAP jest rodzajem RPC.)
źródło
Co to jest REST?
REST w oficjalnych słowach, REST jest stylem architektonicznym zbudowanym na pewnych zasadach przy użyciu aktualnych podstaw „Sieci”. Istnieje 5 podstawowych zasad sieci, które są wykorzystywane do tworzenia usług REST.
źródło
Communication is Done by Representation
znaczyWidzę wiele odpowiedzi, które mówią, że umieszczenie wszystkiego o użytkowniku 123 w zasobie „/ user / 123” jest pełne.
Roy Fielding, który wymyślił ten termin, mówi, że interfejsy API REST muszą być oparte na hipertekstie . W szczególności „Interfejs API REST nie może definiować stałych nazw zasobów ani hierarchii”.
Więc jeśli ścieżka „/ user / 123” jest na stałe zakodowana na kliencie, to tak naprawdę nie jest RESTful. Dobre wykorzystanie HTTP może, a może nie. Ale nie RESTful. Musi pochodzić z hipertekstu.
źródło
Odpowiedź jest bardzo prosta, jest rozprawa napisana przez Roya Fieldinga.] 1 W rozprawie określa zasady REST. Jeśli aplikacja spełnia wszystkie te zasady, jest to aplikacja REST.
Termin RESTful został utworzony, ponieważ ppl wyczerpał słowo REST, nazywając swoją aplikację inną niż REST jako REST. Po tym czasie termin RESTful również się wyczerpał. Obecnie mówimy o interfejsach API sieci Web i interfejsach API Hypermedia , ponieważ większość tak zwanych aplikacji REST nie spełniała części HATEOAS jednolitego ograniczenia interfejsu.
Ograniczenia REST są następujące:
architektura klient-serwer
Więc nie działa na przykład z gniazdami PUB / SUB, jest oparty na REQ / REP.
bezpaństwowa komunikacja
Tak więc serwer nie utrzymuje stanów klientów. Oznacza to, że nie można użyć serwera do przechowywania sesji bocznych i należy uwierzytelnić każde żądanie. Twoi klienci prawdopodobnie wysyłają podstawowe nagłówki uwierzytelniania za pomocą szyfrowanego połączenia. (Przy dużych aplikacjach trudno jest utrzymać wiele sesji.)
użycie pamięci podręcznej, jeśli możesz
Dzięki temu nie musisz ciągle obsługiwać tych samych żądań.
jednolity interfejs jako wspólna umowa między klientem a serwerem
Serwer nie utrzymuje umowy między klientem a serwerem. Innymi słowy, klient musi być oddzielony od wdrożenia usługi. Możesz osiągnąć ten stan, używając standardowych rozwiązań, takich jak standard IRI (URI) do identyfikacji zasobów, standard HTTP do wymiany wiadomości, standardowe typy MIME do opisania formatu serializacji treści, metadane (ewentualnie słowniki RDF, mikroformaty itp.) opisać semantykę różnych części treści wiadomości. Aby oddzielić strukturę IRI od klienta, musisz wysyłać hiperłącza do klientów w formatach hipermedia, takich jak (HTML, JSON-LD, HAL itp.). Tak więc klient może wykorzystać metadane (ewentualnie relacje łącza, słowniki RDF) przypisane do hiperłączy, aby nawigować maszyną stanu aplikacji przez odpowiednie przejścia stanu w celu osiągnięcia bieżącego celu.
Na przykład, gdy klient chce wysłać zamówienie do sklepu internetowego, musi sprawdzić hiperłącza w odpowiedziach wysłanych przez sklep internetowy. Sprawdzając linki, znajduje jeden opisany w http://schema.org/OrderAction . Klient zna słownictwo schema.org, więc rozumie, że poprzez aktywację tego hiperłącza wyśle zamówienie. Aktywuje więc hiperłącze i wysyła
POST https://example.com/api/v1/order
wiadomość z odpowiednim ciałem. Następnie usługa przetwarza wiadomość i odpowiada, otrzymując odpowiedni nagłówek statusu HTTP, na przykład201 - created
przez sukces. Aby dodawać adnotacje do wiadomości ze szczegółowymi metadanymi, standardowe rozwiązanie do korzystania z formatu RDF, na przykład JSON-LD ze słownikiem REST, na przykład Hydra i specyficzne dla domeny, takie jakschema.org lub inny połączony słownik danycha może w razie potrzeby niestandardowy słownictwo specyficzne dla aplikacji. Teraz nie jest to łatwe, dlatego większość ppl używa HAL i innych prostych formatów, które zwykle zapewniają tylko słownictwo REST, ale nie obsługują połączonych danych.zbuduj system warstwowy, aby zwiększyć skalowalność
System REST składa się z warstw hierarchicznych. Każda warstwa zawiera komponenty korzystające z usług komponentów znajdujących się w następnej warstwie poniżej. Możesz więc dodawać nowe warstwy i komponenty bez wysiłku.
Na przykład istnieje warstwa klienta, która zawiera klientów, a poniżej znajduje się warstwa usługi, która zawiera pojedynczą usługę. Teraz możesz dodać między nimi pamięć podręczną po stronie klienta. Następnie możesz dodać kolejną instancję usługi i moduł równoważenia obciążenia itd. ... Kod klienta i kod usługi nie zmienią się.
kod na żądanie w celu rozszerzenia funkcjonalności klienta
To ograniczenie jest opcjonalne. Na przykład możesz wysłać parser dla określonego typu nośnika do klienta itd. Aby to zrobić, możesz potrzebować standardowego systemu ładującego wtyczki w kliencie, lub twój klient zostanie połączony z rozwiązaniem ładującym wtyczki .
Ograniczenia REST dają wysoce skalowalny system, w którym klienci są oddzieleni od implementacji usług. Dzięki temu klienci mogą być wielokrotnego użytku, podobnie jak przeglądarki w Internecie. Klienci i usługi mają te same standardy i słownictwo, dzięki czemu mogą się nawzajem rozumieć, mimo że klient nie zna szczegółów wdrożenia usługi. Umożliwia to tworzenie zautomatyzowanych klientów, którzy mogą znajdować i wykorzystywać usługi REST do osiągnięcia swoich celów. W dłuższej perspektywie klienci ci mogą się ze sobą komunikować i ufać sobie z zadaniami, tak jak robią to ludzie. Jeśli dodamy wzorce uczenia się do takich klientów, wynikiem będzie co najmniej jedna sztuczna inteligencja korzystająca z sieci maszyn zamiast jednego parku serwerów. Na koniec marzenie Bernersa Lee: sieć semantyczna i sztuczna inteligencja staną się rzeczywistością. Tak więc w 2030 r. Skończyliśmy jako Skynet. Dopóki ... ;-)
źródło
RESTful (Reprezentatywny transfer stanu) Programowanie API polega na pisaniu aplikacji internetowych w dowolnym języku programowania zgodnie z 5 podstawowymi zasadami architektury oprogramowania :
Innymi słowy, piszesz proste aplikacje sieciowe punkt-punkt za pośrednictwem HTTP, które używają czasowników takich jak GET, POST, PUT lub DELETE poprzez implementację architektury RESTful, która proponuje standaryzację interfejsu, który udostępnia każdy „zasób”. To nic innego, jak korzystanie z obecnych funkcji sieci w prosty i skuteczny sposób (wysoce udana, sprawdzona i rozproszona architektura). Jest to alternatywa dla bardziej złożonych mechanizmów, takich jak SOAP , CORBA i RPC .
RESTful programowanie jest zgodne z projektowaniem architektury sieci, a przy prawidłowym wdrożeniu pozwala w pełni wykorzystać skalowalną infrastrukturę sieci.
źródło
Gdybym musiał zredukować oryginalną rozprawę na temat REST do zaledwie 3 krótkich zdań, myślę, że następujące oddaje jej istotę:
Po tym łatwo debatować na temat adaptacji, konwencji kodowania i najlepszych praktyk.
Co ciekawe, w rozprawie nie wspomniano o operacjach POST, GET, DELETE ani PUT HTTP. To musi być czyjaś późniejsza interpretacja „najlepszej praktyki” dla „jednolitego interfejsu”.
Jeśli chodzi o usługi sieciowe, wydaje się, że potrzebujemy sposobu rozróżnienia architektur opartych na WSDL i SOAP, które dodają znaczny narzut i prawdopodobnie niepotrzebną złożoność interfejsu. Wymagają również dodatkowych ram i narzędzi programistycznych w celu wdrożenia. Nie jestem pewien, czy REST jest najlepszym terminem na rozróżnienie między zdroworozsądkowymi interfejsami a nadmiernie zaprojektowanymi interfejsami, takimi jak WSDL i SOAP. Ale potrzebujemy czegoś.
źródło
REST to architektoniczny wzorzec i styl pisania rozproszonych aplikacji. To nie jest styl programowania w wąskim znaczeniu.
Powiedzenie, że używasz stylu REST, jest podobne do powiedzenia, że zbudowałeś dom w określonym stylu: na przykład Tudor lub Victorian. Zarówno REST jako styl oprogramowania, jak i Tudor lub Victorian jako styl domowy mogą być zdefiniowane przez cechy i ograniczenia, które je tworzą. Na przykład REST musi mieć separację Klient-Serwer, w której komunikaty są samoopisujące. Domy w stylu Tudorów mają nakładające się szczyty i Dachy, które są stromo pochylone szczytami skierowanymi do przodu. Możesz przeczytać rozprawę Roya, aby dowiedzieć się więcej o ograniczeniach i cechach składających się na REST.
REST, w przeciwieństwie do stylów domowych, miał trudności z konsekwentnym i praktycznym stosowaniem. To mogło być celowe. Pozostawienie faktycznej implementacji projektantowi. Masz więc swobodę robienia tego, co chcesz, o ile spełniasz ograniczenia określone w rozprawie, w której tworzysz systemy REST.
Premia:
Cała sieć oparta jest na REST (lub REST był oparty na sieci). Dlatego jako twórca stron internetowych możesz być tego świadomy, chociaż pisanie dobrych aplikacji internetowych nie jest konieczne.
źródło
Oto mój podstawowy zarys REST. Próbowałem zademonstrować sposób myślenia za każdym z elementów w architekturze RESTful, aby zrozumienie koncepcji było bardziej intuicyjne. Mam nadzieję, że pomoże to niektórym ludziom zdemistyfikować REST!
REST (Representational State Transfer) to architektura projektowa, która określa, w jaki sposób zasoby sieciowe (tj. Węzły współużytkujące informacje) są projektowane i adresowane. Ogólnie architektura RESTful sprawia, że klient (maszyna żądająca) i serwer (maszyna odpowiadająca) mogą żądać odczytu, zapisu i aktualizacji danych bez konieczności posiadania przez klienta wiedzy o tym, jak działa serwer i serwer może przejść wrócił bez potrzeby wiedzieć o kliencie. Okej, spoko ... ale jak to robimy w praktyce?
Najbardziej oczywistym wymaganiem jest to, że musi istnieć jakiś uniwersalny język, aby serwer mógł powiedzieć klientowi, co próbuje zrobić z żądaniem i aby serwer odpowiedział.
Ale aby znaleźć dowolny zasób, a następnie powiedzieć klientowi, gdzie ten zasób żyje, musi istnieć uniwersalny sposób wskazywania zasobów. To tutaj przychodzą uniwersalne identyfikatory zasobów (URI); są to w zasadzie unikalne adresy do wyszukiwania zasobów.
Ale architektura REST na tym się nie kończy! Chociaż powyższe spełnia podstawowe potrzeby tego, czego chcemy, chcemy również mieć architekturę, która obsługuje ruch o dużym natężeniu ruchu, ponieważ dowolny serwer zazwyczaj obsługuje odpowiedzi od wielu klientów. Dlatego nie chcemy przytłaczać serwera, zapamiętując informacje o poprzednich żądaniach.
Dlatego nakładamy ograniczenie, że każda para żądanie-odpowiedź między klientem a serwerem jest niezależna, co oznacza, że serwer nie musi pamiętać o poprzednich żądaniach (poprzednich stanach interakcji klient-serwer), aby odpowiedzieć na nowe żądanie. Oznacza to, że chcemy, aby nasze interakcje były bezpaństwowe.
Aby jeszcze bardziej zmniejszyć obciążenie naszego serwera ponawianiem obliczeń wykonanych ostatnio dla danego klienta, REST umożliwia także buforowanie. Zasadniczo buforowanie oznacza wykonanie migawki początkowej odpowiedzi udzielonej klientowi. Jeśli klient ponownie wyśle to samo żądanie, serwer może dostarczyć klientowi migawkę zamiast ponawiać wszystkie obliczenia, które były niezbędne do utworzenia początkowej odpowiedzi. Ponieważ jednak jest to migawka, jeśli migawka nie wygasła - serwer z góry określa czas wygaśnięcia - a odpowiedź została zaktualizowana od początkowej pamięci podręcznej (tzn. Żądanie dałoby inną odpowiedź niż buforowana odpowiedź) , klient nie zobaczy aktualizacji, dopóki pamięć podręczna nie wygaśnie (lub pamięć podręczna nie zostanie wyczyszczona), a odpowiedź zostanie ponownie wyświetlona od zera.
Ostatnią rzeczą, którą często tu jesteś o architekturach RESTful, jest to, że są one warstwowe. Właściwie już domyślnie omawialiśmy ten wymóg w naszej dyskusji na temat interakcji między klientem a serwerem. Zasadniczo oznacza to, że każda warstwa w naszym systemie oddziałuje tylko z sąsiednimi warstwami. Tak więc w naszej dyskusji warstwa klienta współdziała z naszą warstwą serwera (i odwrotnie), ale mogą istnieć inne warstwy serwera, które pomagają serwerowi głównemu przetworzyć żądanie, z którym klient nie komunikuje się bezpośrednio. Zamiast tego serwer przekazuje żądanie w razie potrzeby.
Teraz, jeśli wszystko to brzmi znajomo, to świetnie. Hypertext Transfer Protocol (HTTP), który definiuje protokół komunikacyjny za pośrednictwem sieci WWW, jest implementacją abstrakcyjnego pojęcia architektury RESTful (lub instancji klasy REST, jeśli jesteś fanatykiem OOP takim jak ja). W tej implementacji REST klient i serwer współdziałają za pośrednictwem GET, POST, PUT, DELETE itp., Które są częścią uniwersalnego języka, a zasoby można wskazać za pomocą adresów URL.
źródło
Myślę, że celem spokoju jest rozdzielenie stanu na wyższą warstwę przy jednoczesnym wykorzystaniu Internetu (protokołu) jako bezpaństwowej warstwy transportowej . Większość innych podejść miesza różne rzeczy.
Jest to najlepsze praktyczne podejście do radzenia sobie z podstawowymi zmianami programowania w erze Internetu. Jeśli chodzi o podstawowe zmiany, Erik Meijer ma dyskusję na temat pokazów tutaj: http://www.infoq.com/interviews/erik-meijer-programming-language-design-effects-purity#view_93197 . Podsumowuje to jako pięć efektów i przedstawia rozwiązanie, projektując je w języku programowania. Rozwiązanie można również osiągnąć na poziomie platformy lub systemu, niezależnie od języka. Spokojny może być postrzegany jako jedno z rozwiązań, które okazało się bardzo skuteczne w obecnej praktyce.
Spokojny styl pozwala uzyskać i manipulować stanem aplikacji w niewiarygodnym Internecie. Jeśli bieżąca operacja nie powiedzie się, aby uzyskać poprawny i bieżący stan, potrzebuje głównej zasady zerowania, aby aplikacja mogła kontynuować. Jeśli nie manipuluje stanem, zwykle używa wielu etapów potwierdzenia, aby wszystko było prawidłowe. W tym sensie reszta sama w sobie nie jest rozwiązaniem, potrzebuje funkcji w innej części stosu aplikacji WWW do obsługi jej działania.
Biorąc pod uwagę ten punkt widzenia, styl odpoczynku nie jest tak naprawdę związany z Internetem ani aplikacją internetową. Jest to podstawowe rozwiązanie wielu sytuacji programowania. To też nie jest proste, po prostu sprawia, że interfejs jest naprawdę prosty, i radzi sobie niesamowicie dobrze z innymi technologiami.
Tylko mój 2c.
Edycja: Dwa inne ważne aspekty:
Bezpaństwowość wprowadza w błąd. Chodzi o spokojny interfejs API, a nie aplikację lub system. System musi być stanowy. Restful design polega na zaprojektowaniu stanowego systemu opartego na bezstanowym API. Niektóre cytaty z innej kontroli jakości :
Idempotencja : Często pomijaną częścią REST jest idempotencja większości czasowników. Prowadzi to do niezawodnych systemów i mniejszej współzależności dokładnych interpretacji semantyki .
źródło
To niezwykle długa „dyskusja”, a jednocześnie dość myląca co najmniej.
IMO:
1) Nie ma czegoś takiego jak spokojne programowanie, bez dużego stawu i dużej ilości piwa :)
2) Reprezentatywny transfer stanu (REST) to styl architektoniczny określony w rozprawie Roy Fieldinga . Ma wiele ograniczeń. Jeśli Twoja usługa / klient ich przestrzega, oznacza to, że RESTful. To jest to.
Możesz podsumować (znacząco) ograniczenia do:
Jest jeszcze jeden bardzo dobry post, który ładnie wyjaśnia sprawy.
Wiele odpowiedzi kopiuje / wkleja prawidłowe informacje, mieszając je i wprowadzając pewne zamieszanie. Ludzie mówią tutaj o poziomach, o RESTFul URI (nie ma czegoś takiego!), Stosują metody HTTP GET, POST, PUT ... REST nie dotyczy tego lub nie tylko tego.
Na przykład linki - fajnie jest mieć pięknie wyglądający interfejs API, ale na końcu klient / serwer tak naprawdę nie dba o linki, które otrzymujesz / wysyłasz, to treść, która ma znaczenie.
W końcu każdy klient RESTful powinien móc korzystać z dowolnej usługi RESTful, o ile znany jest format treści.
źródło
Stare pytanie, nowy sposób odpowiedzi. Istnieje wiele nieporozumień na temat tej koncepcji. Zawsze staram się pamiętać:
Programowanie spokojne określam jako
Aby być spokojnym programistą, musisz próbować budować aplikacje, które pozwalają aktorom robić różne rzeczy. Nie tylko ujawnianie bazy danych.
Kontrola przejścia stanu ma sens tylko wtedy, gdy klient i serwer zgadzają się na reprezentację typu medialnego zasobu. W przeciwnym razie nie ma sposobu, aby dowiedzieć się, co jest formantem, a co nie i jak wykonać kontrolę. IE, gdyby przeglądarki nie znały
<form>
tagów w html, nie byłoby nic do przesłania do stanu przejścia w przeglądarce.Nie chcę się promować, ale pogłębiam te pomysły dogłębnie w moim wykładzie http://techblog.bodybuilding.com/2016/01/video-what-is-restful-200.html .
Fragment mojego przemówienia dotyczy często odwoływanego do modelu dojrzałości Richardsona, nie wierzę w poziomy, albo jesteś ODPOCZYNYWANY (poziom 3), albo nie, ale to, co lubię o tym mówić, to to, co każdy poziom robi dla ciebie w drodze do RESTful
źródło
REST definiuje 6 ograniczeń architektonicznych, które czynią każdą usługę internetową - prawdziwym API RESTful .
https://restfulapi.net/rest-architectural-constraints/
źródło
REST === Analogia HTTP jest nieprawidłowa, dopóki nie zaakcentujesz faktu, że „MUSI” być nienawiścią sterowana przez .
Sam Roy to tutaj wyjaśnił .
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ślone (lub ograniczone przez) wiedzę klienta na temat rodzajów mediów i mechanizmów komunikacji zasobów, z których oba mogą być ulepszane w locie (np. Kod na żądanie).
[Błąd tutaj oznacza, że informacje pozapasmowe napędzają interakcję zamiast hipertekstu.]
źródło
W architekturze opartej na REST wszystko jest zasobem (Użytkownicy, Zamówienia, Komentarze). Dostęp do zasobu odbywa się za pośrednictwem wspólnego interfejsu opartego na standardowych metodach HTTP (GET, PUT, PATCH, DELETE itp.).
Każdy zasób powinien obsługiwać typowe operacje HTTP. Zasoby są identyfikowane za pomocą globalnych identyfikatorów (które zazwyczaj są identyfikatorami URI).
REST pozwala, aby zasoby miały różne reprezentacje, np. Tekst, XML, JSON itp. Klient REST może poprosić o określoną reprezentację za pośrednictwem protokołu HTTP (negocjacja treści).
Metody HTTP:
Metody PUT, GET, POST i DELETE są typowo stosowane w architekturach opartych na REST. Poniższa tabela zawiera wyjaśnienie tych operacji.
źródło
REST oznacza reprezentatywny transfer stanu .
Opiera się na bezstanowym protokole komunikacyjnym klient-serwer, buforowalnym - i praktycznie we wszystkich przypadkach używany jest protokół HTTP.
REST jest często używany w aplikacjach mobilnych, serwisach społecznościowych, narzędziach do łączenia stron i zautomatyzowanych procesach biznesowych. Styl REST podkreśla, że interakcje między klientami a usługami są wzmocnione dzięki ograniczonej liczbie operacji (czasowników). Elastyczność zapewnia się poprzez przypisywanie zasobom (rzeczownikom) ich unikalnych uniwersalnych wskaźników zasobów (URI).
Wprowadzenie o odpoczynku
źródło
Rozmowa to coś więcej niż wymiana informacji . Protokół jest tak zaprojektowany, że nie trzeba rozmawiać. Każda ze stron wie, jakie jest ich konkretne zadanie, ponieważ jest ono określone w protokole. Protokoły pozwalają na czystą wymianę informacji kosztem wszelkich zmian w możliwych działaniach. Z drugiej strony rozmowa pozwala jednej ze stron zapytać, jakie dalsze działania można podjąć od drugiej strony. Mogą nawet zadać to samo pytanie dwa razy i uzyskać dwie różne odpowiedzi, ponieważ stan drugiej strony mógł się w międzyczasie zmienić. Mówienie to architektura RESTful . Teza Fieldinga określa architekturę, którą należy zastosować, jeśli chce się, aby maszyny mogły ze sobą rozmawiać, a nie po prostukomunikować się .
źródło
Nie ma takiego pojęcia jak „programowanie RESTful” jako takie. Lepiej byłoby to nazwać paradygmatem RESTful lub nawet lepszą architekturą RESTful. To nie jest język programowania. To jest paradygmat.
Z Wikipedii :
źródło
Chodzi o to, że jeśli zgodzimy się używać wspólnego języka dla podstawowych operacji (czasowników http), infrastrukturę można skonfigurować tak, aby ją rozumiała i optymalizowała prawidłowo, na przykład poprzez wykorzystanie nagłówków buforowania w celu zaimplementowania buforowania w ogóle poziomy.
Przy prawidłowo wdrożonej operacji GET typu restful nie powinno mieć znaczenia, czy informacje pochodzą z bazy danych serwera, pamięci podręcznej serwera, sieci CDN, pamięci podręcznej serwera proxy, pamięci podręcznej przeglądarki lub lokalnego magazynu przeglądarki. Można użyć najszybszego, najłatwiej dostępnego i aktualnego źródła.
Powiedzenie, że Rest jest tylko zmianą składniową od używania żądań GET z parametrem działania do używania dostępnych czasowników http, sprawia, że wygląda na to, że nie ma żadnych korzyści i jest czysto kosmetyczny. Chodzi o to, aby użyć języka, który można zrozumieć i zoptymalizować w każdej części łańcucha. Jeśli operacja GET ma działanie niepożądane, musisz pominąć buforowanie HTTP, w przeciwnym razie uzyskasz niespójne wyniki.
źródło
Co to jest testowanie interfejsu API ?
Testowanie API wykorzystuje programowanie do wysyłania wywołań do API i uzyskiwania zysków. Testowanie traktuje testowany segment jako czarną skrzynkę. Celem testowania API jest potwierdzenie poprawnego wykonania i błędnego traktowania części poprzedzającej jej koordynację w aplikacji.
Interfejs API REST
REST: Reprezentatywny transfer stanu.
4 powszechnie stosowane metody API: -
Kroki ręcznego testowania interfejsu API: -
Aby ręcznie korzystać z API, możemy użyć wtyczek REST API opartych na przeglądarce.
Kroki automatyzacji interfejsu API REST
źródło
Jest to bardzo rzadko wspominane wszędzie, ale model dojrzałości Richardsona jest jedną z najlepszych metod oceny, w jaki sposób Restful jest API. Więcej o tym tutaj:
Model dojrzałości Richardsona
źródło
Powiedziałbym, że ważnym elementem w zrozumieniu REST są punkty końcowe lub odwzorowania, takie jak
/customers/{id}/balance
.Możesz sobie wyobrazić taki punkt końcowy jako potok łączący stronę internetową (front-end) z bazą danych / serwerem (back-end). Korzystając z nich, front-end może wykonywać operacje zaplecza zdefiniowane w odpowiednich metodach dowolnego mapowania REST w aplikacji.
źródło