Czym dokładnie jest programowanie RESTful?

Czym dokładnie jest programowanie RESTful?

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, POSTi DELETEżądania należy wykorzystywać odpowiednio do mutacji, tworzenia i usuwania .

Zwolennicy REST preferują adresy URL, takie jak

http://myserver.com/catalog/item/1729

ale architektura REST nie wymaga tych „ładnych adresów URL”. Żądanie GET z parametrem

http://myserver.com/catalog?item=1729

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

http://myserver.com/addToCart?cart=314159&item=1729

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 ”.

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ą GETi POST, myślę, że wszyscy je rozpoznają. Jednak standard HTTP definiuje kilka innych, takich jak PUTi DELETE. 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+userdbi application/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 :

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 narzutów z włączonym hipertekstem dla istniejących standardowych typów mediów.

Żądanie zasobu podstawowego /może zwrócić coś takiego:

Żądanie

GET /
Accept: application/json+userdb

Odpowiedź

200 OK
Content-Type: application/json+userdb

{
    "version": "1.0",
    "links": [
        {
            "href": "/user",
            "rel": "list",
            "method": "GET"
        },
        {
            "href": "/user",
            "rel": "create",
            "method": "POST"
        }
    ]
}

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

GET /user
Accept: application/json+userdb

Odpowiedź

200 OK
Content-Type: application/json+userdb

{
    "users": [
        {
            "id": 1,
            "name": "Emil",
            "country: "Sweden",
            "links": [
                {
                    "href": "/user/1",
                    "rel": "self",
                    "method": "GET"
                },
                {
                    "href": "/user/1",
                    "rel": "edit",
                    "method": "PUT"
                },
                {
                    "href": "/user/1",
                    "rel": "delete",
                    "method": "DELETE"
                }
            ]
        },
        {
            "id": 2,
            "name": "Adam",
            "country: "Scotland",
            "links": [
                {
                    "href": "/user/2",
                    "rel": "self",
                    "method": "GET"
                },
                {
                    "href": "/user/2",
                    "rel": "edit",
                    "method": "PUT"
                },
                {
                    "href": "/user/2",
                    "rel": "delete",
                    "method": "DELETE"
                }
            ]
        }
    ],
    "links": [
        {
            "href": "/user",
            "rel": "create",
            "method": "POST"
        }
    ]
}

Z tej odpowiedzi możemy wiele powiedzieć. Na przykład, teraz wiemy, możemy utworzyć nowego użytkownika przez POSTING /user:

Żądanie

POST /user
Accept: application/json+userdb
Content-Type: application/json+userdb

{
    "name": "Karl",
    "country": "Austria"
}

Odpowiedź

201 Created
Content-Type: application/json+userdb

{
    "user": {
        "id": 3,
        "name": "Karl",
        "country": "Austria",
        "links": [
            {
                "href": "/user/3",
                "rel": "self",
                "method": "GET"
            },
            {
                "href": "/user/3",
                "rel": "edit",
                "method": "PUT"
            },
            {
                "href": "/user/3",
                "rel": "delete",
                "method": "DELETE"
            }
        ]
    },
    "links": {
       "href": "/user",
       "rel": "list",
       "method": "GET"
    }
}

Wiemy również, że możemy zmienić istniejące dane:

Żądanie

PUT /user/1
Accept: application/json+userdb
Content-Type: application/json+userdb

{
    "name": "Emil",
    "country": "Bhutan"
}

Odpowiedź

200 OK
Content-Type: application/json+userdb

{
    "user": {
        "id": 1,
        "name": "Emil",
        "country": "Bhutan",
        "links": [
            {
                "href": "/user/1",
                "rel": "self",
                "method": "GET"
            },
            {
                "href": "/user/1",
                "rel": "edit",
                "method": "PUT"
            },
            {
                "href": "/user/1",
                "rel": "delete",
                "method": "DELETE"
            }
        ]
    },
    "links": {
       "href": "/user",
       "rel": "list",
       "method": "GET"
    }
}

Zauważ, że używamy różnych zleceń HTTP ( GET, PUT, POST, DELETEitd.), Aby manipulować tych zasobów, i że tylko wiedza zakładamy ze strony klienta jest nasza definicja mediów.

Dalsza lektura:

• O wiele lepsze odpowiedzi na tej samej stronie.
• Jak wyjaśniłem REST mojej żonie .
• Jak wyjaśniłem REST mojej żonie .
• Myśli Martina Fowlera
• Interfejs API PayPal ma kontrolę nad hipermedia

(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).

Programowanie RESTful polega na:

• zasoby identyfikowane za pomocą trwałego identyfikatora: identyfikatory URI są obecnie wszechobecnym wyborem identyfikatora
• Zasoby są manipulowane za pomocą wspólnego zestawu czasowników: http metody są powszechnie postrzegane przypadek - czcigodny Create, Retrieve, Update, Deletestaje POST, GET, PUT, i DELETE. Ale REST nie ogranicza się do HTTP, jest to obecnie najczęściej używany transport.
• rzeczywista reprezentacja pobrana dla zasobu zależy od żądania, a nie od identyfikatora: użyj nagłówków Accept, aby kontrolować, czy chcesz XML, HTTP, a nawet obiekt Java reprezentujący zasób
• utrzymywanie stanu w obiekcie i reprezentowanie stanu w reprezentacji
• reprezentujący relacje między zasobami w reprezentacji zasobu: połączenia między obiektami są osadzone bezpośrednio w reprezentacji
• reprezentacje zasobów opisują, w jaki sposób można korzystać z tej reprezentacji i pod jakimi warunkami należy ją wyrzucać / ponownie pobierać w spójny sposób: użycie nagłówków HTTP Cache-Control

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.

Tak może to wyglądać.

Utwórz użytkownika z trzema właściwościami:

POST /user
fname=John&lname=Doe&age=25

Serwer odpowiada:

200 OK
Location: /user/123

W przyszłości możesz pobrać informacje o użytkowniku:

GET /user/123

Serwer odpowiada:

200 OK
<fname>John</fname><lname>Doe</lname><age>25</age>

Aby zmodyfikować rekord ( lnamei agepozostanie niezmieniony):

PATCH /user/123
fname=Johnny

Aby zaktualizować rekord (aw konsekwencji lnamei agebędzie NULL):

PUT /user/123
fname=Johnny

Ś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 .

Ograniczenie HATEOAS to skrót od Hypermedia jako Engine of Application State. Ta zasada jest kluczowym czynnikiem odróżniającym REST od większości innych form systemu serwerowego klienta.

...

Klient aplikacji RESTful musi znać tylko jeden stały adres URL, aby uzyskać do niego dostęp. Wszystkie przyszłe działania powinny być wykrywalne dynamicznie z hipermedialnych łączy zawartych w reprezentacjach zasobów zwracanych z tego adresu URL. Oczekuje się, że znormalizowane typy nośników będą zrozumiałe dla każdego klienta, który może korzystać z interfejsu API RESTful. (Z Wikipedii, wolnej encyklopedii)

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ę

Co to jest REST?

REST to skrót od Representative State Transfer. (Czasami jest napisane „ReST”.) Opiera się na bezstanowym, klienckim serwerze komunikacyjnym, buforowanym protokole komunikacyjnym - i praktycznie we wszystkich przypadkach używany jest protokół HTTP.

REST to styl architektury do projektowania aplikacji sieciowych. Chodzi o to, że zamiast używać złożonych mechanizmów, takich jak CORBA, RPC lub SOAP, do łączenia się między komputerami, do nawiązywania połączeń między komputerami używa się prostego protokołu HTTP.

Na wiele sposobów samą sieć WWW opartą na HTTP można postrzegać jako architekturę opartą na REST. Aplikacje RESTful używają żądań HTTP do publikowania danych (tworzenia i / lub aktualizacji), odczytu danych (np. Wykonywania zapytań) i usuwania danych. Dlatego REST używa HTTP dla wszystkich czterech operacji CRUD (Utwórz / Odczyt / Aktualizuj / Usuń).

REST jest lekką alternatywą dla mechanizmów takich jak RPC (Remote Procedural Call Calls) i Web Services (SOAP, WSDL i in.). Później przekonamy się, o ile prostszy jest REST.

Pomimo tego, że jest prosty, REST jest w pełni funkcjonalny; zasadniczo nie można nic zrobić w usługach sieci Web, czego nie można zrobić przy użyciu architektury RESTful. REST nie jest „standardem”. Na przykład nigdy nie będzie rekomendacji W3C dla REST. I chociaż istnieją ramy programistyczne REST, praca z REST jest tak prosta, że ​​często można „rozwinąć własną” dzięki standardowym funkcjom biblioteki w językach takich jak Perl, Java lub C #.

Jedno z najlepszych odniesień, jakie znalazłem, gdy próbowałem znaleźć proste prawdziwe znaczenie odpoczynku.

http://rest.elkstein.org/

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:

GET /delete_user.x?id=123
GET /user/delete
GET /new_user.x
GET /user/new
GET /user?id=1
GET /user/id/1

Używasz „czasowników” HTTP i masz ...

GET /user/2
DELETE /user/2
PUT /user

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.

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

REST to styl architektury do projektowania aplikacji sieciowych. Chodzi o to, że zamiast używać złożonych mechanizmów, takich jak CORBA, RPC lub SOAP, do łączenia się między komputerami, do nawiązywania połączeń między komputerami używa się prostego protokołu HTTP.

• Na wiele sposobów samą sieć WWW opartą na HTTP można postrzegać jako architekturę opartą na REST.

Aplikacje RESTful używają żądań HTTP do publikowania danych (tworzenia i / lub aktualizacji), odczytu danych (np. Wykonywania zapytań) i usuwania danych. Dlatego REST używa HTTP dla wszystkich czterech operacji CRUD (Utwórz / Odczyt / Aktualizuj / Usuń).

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.

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.)

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.

• Zasada 1: Wszystko jest zasobem W stylu REST dane i funkcjonalność są uważane za zasoby i są dostępne za pomocą identyfikatorów URI (Uniform Resource Identifier), zwykle łączy w Internecie.
• Zasada 2: Każdy zasób jest identyfikowany unikalnym identyfikatorem (URI)
• Zasada 3: Używaj prostych i jednolitych interfejsów
• Zasada 4: Komunikacja odbywa się przez przedstawicielstwo
• Zasada 5: Bądź bezpaństwowcem

Widzę 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.

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:

1. architektura klient-serwer

   Więc nie działa na przykład z gniazdami PUB / SUB, jest oparty na REQ / REP.

2. 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.)

3. użycie pamięci podręcznej, jeśli możesz

   Dzięki temu nie musisz ciągle obsługiwać tych samych żądań.

4. 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/orderwiadomość z odpowiednim ciałem. Następnie usługa przetwarza wiadomość i odpowiada, otrzymując odpowiedni nagłówek statusu HTTP, na przykład 201 - createdprzez 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.

5. 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ę.

6. 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 ... ;-)

RESTful (Reprezentatywny transfer stanu) Programowanie API polega na pisaniu aplikacji internetowych w dowolnym języku programowania zgodnie z 5 podstawowymi zasadami architektury oprogramowania :

1. Zasób (dane, informacje).
2. Unikalny globalny identyfikator (wszystkie zasoby są unikatowo identyfikowane przez URI ).
3. Jednolity interfejs - użyj prostego i standardowego interfejsu (HTTP).
4. Reprezentacja - cała komunikacja odbywa się poprzez reprezentację (np. XML / JSON )
5. Bezstanowy (każde żądanie odbywa się w pełnej izolacji, łatwiej jest buforować i równoważić obciążenie),

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.

Gdybym musiał zredukować oryginalną rozprawę na temat REST do zaledwie 3 krótkich zdań, myślę, że następujące oddaje jej istotę:

1. Zasoby są wymagane za pośrednictwem adresów URL.
2. Protokoły są ograniczone do tego, co możesz komunikować się za pomocą adresów URL.
3. Metadane są przekazywane jako pary nazwa-wartość (dane wpisu i parametry ciągu zapytania).

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ś.

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.

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.

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 :

  • REST działa na reprezentacjach zasobów, z których każda jest identyfikowana przez adres URL. Zazwyczaj nie są to obiekty danych, ale abstrakcje złożonych obiektów .
  • REST oznacza „reprezentacyjny transfer stanu”, co oznacza, że ​​chodzi o komunikację i modyfikację stanu niektórych zasobów w systemie.

• 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 .

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:

• bezpaństwowa komunikacja
• przestrzegaj specyfikacji HTTP (jeśli używany jest HTTP)
• wyraźnie przekazuje przesyłane formaty treści
• użyj hypermedia jako silnika stanu aplikacji

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.

Stare pytanie, nowy sposób odpowiedzi. Istnieje wiele nieporozumień na temat tej koncepcji. Zawsze staram się pamiętać:

1. Strukturalne adresy URL i metody HTTP / czasowniki nie są definicją spokojnego programowania.
2. JSON nie jest programowaniem kojącym
3. Programowanie RESTful nie jest przeznaczone dla interfejsów API

Programowanie spokojne określam jako

Aplikacja jest spokojna, jeśli zapewnia zasoby (będące kombinacją kontroli danych + przejść między stanami) w typie nośnika, który klient rozumie

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

REST definiuje 6 ograniczeń architektonicznych, które czynią każdą usługę internetową - prawdziwym API RESTful .

1. Jednolity interfejs
2. Klient – ​​serwer
3. Bezpaństwowiec
4. Pamięć podręczna
5. System warstwowy
6. Kod na żądanie (opcjonalnie)

https://restfulapi.net/rest-architectural-constraints/

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.]

REST to styl architektoniczny oparty na standardach internetowych i protokole HTTP (wprowadzonym w 2000 r.).

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.).

W architekturze opartej na REST masz serwer REST, który zapewnia dostęp do zasobów. Klient REST może uzyskiwać dostęp i modyfikować zasoby REST.

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.

• GET określa dostęp do odczytu zasobu bez skutków ubocznych. Zasób nigdy nie jest zmieniany za pomocą żądania GET, np. Żądanie nie ma skutków ubocznych (idempotent).
• PUT tworzy nowy zasób. Musi być także idempotentny.
• DELETE usuwa zasoby. Operacje są idempotentne. Mogą się powtarzać bez powodowania różnych wyników.
• POST aktualizuje istniejący zasób lub tworzy nowy zasób.

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

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ę .

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 :

W obliczeniach reprezentatywny transfer stanu (REST) ​​to styl architektoniczny wykorzystywany do tworzenia stron internetowych.

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.

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.

• Jest to układ funkcji, na których testerzy wykonują żądania i odbierają odpowiedzi. W REST API interakcje są dokonywane za pomocą protokołu HTTP.
• REST pozwala również na komunikację między komputerami przez sieć.
• Do wysyłania i odbierania wiadomości wymaga użycia metod HTTP i nie wymaga ścisłej definicji wiadomości, w przeciwieństwie do usług internetowych.
• Wiadomości REST często akceptują formularz w formacie XML lub JavaScript Object Notation (JSON).

4 powszechnie stosowane metody API: -

1. GET: - Zapewnia dostęp tylko do odczytu do zasobu.
2. POST: - Służy do tworzenia lub aktualizowania nowego zasobu.
3. PUT: - Służy do aktualizacji lub wymiany istniejącego zasobu lub utworzenia nowego zasobu.
4. USUŃ: - Służy do usuwania zasobu.

Kroki ręcznego testowania interfejsu API: -

Aby ręcznie korzystać z API, możemy użyć wtyczek REST API opartych na przeglądarce.

1. Zainstaluj wtyczkę POSTMAN (Chrome) / REST (Firefox)
2. Wpisz adres URL interfejsu API
3. Wybierz metodę REST
4. Wybierz nagłówek zawartości
5. Wpisz zapytanie JSON (POST)
6. Kliknij Wyślij
7. Zwróci odpowiedź wyjściową

Kroki automatyzacji interfejsu API REST

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

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.