Czym dokładnie jest programowanie RESTful?

REST jest podstawową zasadą architektoniczną sieci. Niesamowitą rzeczą w sieci jest fakt, że klienci (przeglądarki) i serwery mogą wchodzić w interakcje w złożony sposób, bez uprzedniej wiedzy klienta o serwerze i zasobach, które hostuje. Kluczowym ograniczeniem jest to, że serwer i klient muszą zgadzać się na media używane, które w przypadku sieci jest HTML.

API, które przestrzega zasad REST nie wymaga, aby klient wiedział cokolwiek o strukturze API. Serwer musi raczej dostarczać wszelkie informacje potrzebne klientowi do interakcji z usługą. Przykładem tego 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. (zasada ta nazywana jest HATEOAS : Hypermedia jako silnik stanu aplikacji .)

Jak to ma zastosowanie do HTTP i jak można to wdrożyć w praktyce? HTTP jest zorientowany na czasowniki i zasoby. Dwa czasowniki w głównym użyciu to GET I POST, które myślę, że każdy rozpozna. Standard HTTP definiuje jednak kilka innych, takich jak PUT I DELETE. Czasowniki te są następnie stosowane do zasobów, zgodnie zgodnie z instrukcjami dostarczonymi przez serwer.

Na przykład, wyobraźmy sobie, że mamy bazę danych użytkowników, która jest zarządzana przez serwis internetowy. Nasza usługa korzysta z niestandardowej hipermedii opartej na JSON, dla której przypisujemy typ MIME application/json + userdb (Może być również application / xml + userdb i application / whatever+userdb - wiele typów nośników może być obsługiwanych). Zarówno klient, jak i serwer zostały zaprogramowane, aby zrozumieć ten format, ale nic o sobie nie wiemy. Jak wskazuje Roy Fielding :

REST API powinien poświęcić prawie cały swój opisowy wysiłek w definiowanie typu (- ów) nośnika (- ów) używanego (- ych) do reprezentowania zasobów i prowadzenia stanu aplikacji, lub przy definiowaniu rozszerzonych nazw relacji i / lub znaczniki z obsługą hipertekstu dla istniejących standardowych typów nośników.

Żądanie zasobu bazowego / może zwrócić coś w rodzaju to:

Zapytanie

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 powiązanych zasobach możemy znaleźć w sekcjach zwanych "linkami". To się nazywa sterowanie Hypermedia . W tym przypadku możemy stwierdzić z takiej sekcji, że możemy znaleźć listę użytkowników, składając kolejne żądanie dla /user:

Zapytanie

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"
        }
    ]
}

Możemy powiedzieć wiele z tej odpowiedzi. Na przykład teraz wiemy, że możemy utworzyć nowego użytkownika, wysyłając wiadomość do /user:

Zapytanie

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"
    }
}

Zapytanie

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 czasowników HTTP (GET, PUT, POST, DELETE itp.) manipulować tymi zasobami i że jedyną wiedzą, którą Zakładamy po stronie klientów, jest nasza definicja mediów.

Czytaj dalej:

• wiele o wiele lepszych odpowiedzi na tej stronie.
• jak wyjaśniłem resztę mojej żonie .
• jak wyjaśniłem odpoczynek mojej żonie.
• Martin Fowler ' s myśli
• Paypal posiada interfejs API hypermedia controls

(ta odpowiedź była przedmiotem sporej krytyki za pominięcie punktu. W większości, to była uczciwa krytyka. To, co pierwotnie opisałem, było bardziej zgodne z tym, jak odpoczynek był zwykle realizowany kilka lat temu, kiedy po raz pierwszy to napisałem, a nie jego prawdziwe znaczenie. Poprawiłem odpowiedź, aby lepiej odzwierciedlała prawdziwe znaczenie.)

RESTful programming jest o:

[11]}zasoby identyfikowane za pomocą trwałego identyfikatora: URI są obecnie wszechobecnym wyborem identyfikatora
• zasoby są manipulowane przy użyciu wspólnego zestawu czasowników: metody HTTP są powszechnie postrzeganym przypadkiem-czcigodny Create, Retrieve, Update, Delete staje się POST, GET, PUT, i DELETE. Ale reszta nie ogranicza się do HTTP, jest to po prostu najczęściej używany transport w tej chwili.
• rzeczywista reprezentacja pobrana zasoby są zależne od żądania, a nie od identyfikatora: użyj nagłówków Akceptuj, aby kontrolować, czy chcesz XML, HTTP, czy nawet obiekt Java reprezentujący zasób
• utrzymanie stanu w obiekcie i reprezentowanie stanu w reprezentacji
• reprezentowanie relacji między zasobami w reprezentacji zasobu: powiązania między obiektami są osadzone bezpośrednio w reprezentacji
• reprezentacje zasobów opisują, jak reprezentacja może być użyta i w jakich okolicznościach powinna być odrzucona/refetchowana w spójny sposób: użycie pamięci podręcznej HTTP-Control headers

Jeśli naprawdę interesuje Cię, czym jest Architektura odpoczynku i dlaczego działa, przeczytaj jego tezę kilka razy i przeczytajcałość nie tylko Rozdział 5! Następnie przyjrzyj się dlaczego DNS działa . Przeczytaj o hierarchicznej organizacji DNS i o tym, jak działają polecenia. Następnie Przeczytaj i zastanów się, jak działa buforowanie DNS. Na koniec przeczytaj specyfikacje HTTP (RFC2616 i RFC3040 w szczególności) i zastanów się, jak i dlaczego buforowanie działa tak, jak to robi. W końcu po prostu kliknie. Ostatecznym objawieniem było dla mnie, gdy zobaczyłem podobieństwo między DNS i HTTP. Po tym, zrozumienie, dlaczego Interfejsy SOA i Message Passing są skalowalne, zaczyna klikać.

Myślę, że najważniejszą sztuczką do zrozumienia znaczenia architektury i implikacji wydajności odpoczynku i dzielone Nic architektur nie pozwala uniknąć przywiązania do technologii i szczegółów implementacji. Skoncentruj się na tym, kto jest właścicielem zasobów, kto jest odpowiedzialny za ich tworzenie/utrzymywanie itp. Następnie pomyśl o reprezentacjach, protokołach i technologiach.

Tak to może wyglądać.

Utwórz użytkownika o trzech właściwościach:

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 (lname i age pozostaną bez zmian):

PATCH /user/123
fname=Johnny

Aby zaktualizować rekord (a w konsekwencji lname i age będą NULL):

PUT /user/123
fname=Johnny

Wielką książką o odpoczynku jest odpoczynek w praktyce.

Must reads are Representational State Transfer (REST) and REST API must be hypertext driven

Zobacz artykuł Martina Fowlersa the Richardson Maturity Model (RMM), aby uzyskać wyjaśnienie, czym jest usługa RESTful.

Aby być 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 jest akronimem dla Hypermedia jako silnik Stan Aplikacji. Zasada ta jest kluczowy różnicnik między odpoczynkiem i większość innych form serwera klienta system.

...

Klient aplikacji RESTful potrzebuje znać tylko jeden stały adres URL, aby uzyskać dostęp to. Wszystkie przyszłe działania powinny być wykrywalne dynamicznie z hipermedia linki zawarte w reprezentacje zasobów, które są zwracane z tego adresu URL. Znormalizowane typy nośników to także oczekuje się, że będzie rozumiana przez każdego klient, który może używać RESTful API. (Z wikipedii, wolnej encyklopedii)

REST Lakmus Test for Web Framework jest podobnym testem dojrzałości dla web framework.

Zbliżanie się do czystego odpoczynku: Nauka kochania HATEOAS jest dobrym zbiorem linków.

Odpoczynek versus SOAP for the Public Cloud omawia aktualne poziomy wykorzystania odpoczynku.

REST and versioning omawia rozszerzalność, wersjonowanie, Ewolucyjność itp. poprzez modyfikację

Czym jest odpoczynek?

REST oznacza Reprezentacyjny Transfer Państwa. (Czasami jest pisane "odpoczynek".) Opiera się na bezstanowym, klient-serwer, cacheable protokół komunikacyjny . i praktycznie we wszystkich przypadkach HTTP protokół jest używany.

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 maszynami, prosty HTTP służy do Marka połączenia między maszynami.

Pod wieloma względami sama sieć WWW, oparta na HTTP, może być oglądana jako architektura oparta na odpoczynku. Aplikacje RESTful wykorzystują żądania HTTP aby opublikować dane( utworzyć i / lub zaktualizować), odczytać dane (np.), i usunąć dane. Tak więc REST używa HTTP dla wszystkich czterech CRUD (Tworzenie/odczyt/aktualizacja/usuwanie) operacji.

REST jest lekką alternatywą dla mechanizmów takich jak RPC (Remote Procedury wywołania) i usług internetowych (SOAP, WSDL, i in.). Później będziemy zobacz, jak prosty jest odpoczynek.

Pomimo prostoty, reszta jest w pełni funkcjonalna; jest w zasadzie nic nie można zrobić w serwisach internetowych, czego nie można zrobić z odpoczynkiem Architektura. Odpoczynek nie jest "standardem". Nigdy nie będzie W3C polecam np. na odpoczynek. A gdy są odpoczynek frameworków programistycznych, praca z REST jest tak prosta, że można często "roll your own" ze standardowymi funkcjami biblioteki w językach takich jak Perl, Java, czy C#.

Jedna z najlepszych referencji, jakie znalazłem, gdy próbuję 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 usuwania metody (powiedzmy, /user/123/delete), możesz wysłać żądanie usunięcia na adres URL /user/[id], aby edytować użytkownika, aby pobrać informacje o użytkowniku, który wysyłasz żądanie GET do /user/[id]

Na przykład, zamiast zestawu adresów URL, które mogą wyglądać jak niektóre z poniższych..

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 HTTP "czasowniki" i masz..

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

To programowanie, w którym Architektura Twojego systemu pasuje do stylu REST określonego przez Roya Fieldinga w jego tezie. Ponieważ jest to styl architektoniczny, który opisuje sieć (mniej lub bardziej), Wiele osób jest nim zainteresowanych.

Bonus odpowiedź: Nie. Chyba że studiujesz architekturę oprogramowania jako naukowiec lub projektujesz Usługi internetowe, naprawdę nie ma powodu, aby usłyszeć to określenie.

Powiedziałbym, że programowanie RESTful polegałoby na tworzeniu systemów (API), które podążają za stylem architektonicznym REST.

Znalazłem ten fantastyczny, krótki i łatwy do zrozumienia tutorial o odpoczynku Dr. M. Elkstein i cytując zasadniczą część, która w większości odpowiada na twoje pytanie:

Learn REST: a Tutorial

REST to styl architektury do projektowania aplikacji sieciowych. Chodzi o to, że zamiast używać złożonych mechanizmy takie jak CORBA, RPC lub SOAP do łączenia się między maszynami, prosty HTTP jest używany do połączenia między maszynami.

[14]}pod wieloma względami sama sieć WWW, oparta na HTTP, może być postrzegana jako architektura oparta na REST.

RESTful applications use HTTP requests to post data (create and / or aktualizować), odczytywać dane (np. tworzyć zapytania) i usuwać dane. Tak więc odpoczynek używa HTTP dla wszystkich czterech operacji CRUD (Create/Read/Update/Delete).

I nie myśl, że powinieneś czuć się głupi, nie słysząc o odpoczynku poza przepełnieniem stosu..., Byłbym w tej samej sytuacji!; odpowiedzi na to drugie pytanie na dlaczego odpoczynek staje się teraz duży może złagodzić pewne uczucia.

Przepraszam, jeśli nie odpowiadam bezpośrednio na pytanie, ale łatwiej jest to zrozumieć bardziej szczegółowymi przykładami. Fielding nie jest łatwy do zrozumienia ze względu na całą abstrakcję i terminologię.

Jest tu dość dobry przykład:

Wyjaśnienie odpoczynku i hipertekstu: Spam-E Robot Czyszczący Spam

I jeszcze lepiej, jest tu czyste Wyjaśnienie z prostymi przykładami (powerpoint jest bardziej wyczerpujący, ale większość można uzyskać w wersja html):

Http://www.xfront.com/REST.ppt lub http://www.xfront.com/REST.html

Po przeczytaniu przykładów zrozumiałem, dlaczego Ken mówi, że reszta jest hipertekstem. Nie jestem jednak pewien, czy ma rację, ponieważ ten/user / 123 jest URI, który wskazuje na zasób i nie jest dla mnie jasne, że jest niepokojący 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 bardzo pomocne. Kiedy Fielding mówi: "To jest RPC. Krzyczy RPC.", jest jasne, że RPC nie jest spokojny, więc warto zobaczyć dokładne przyczyny tego. (Mydło jest rodzajem RPC.)

Czym jest odpoczynek?

REST w oficjalnych słowach, REST to styl architektoniczny zbudowany na pewnych zasadach przy użyciu obecnych" internetowych " podstaw. Istnieje 5 podstawowych podstaw Internetu, które są wykorzystywane do tworzenia usług REST.

• Zasada 1: Wszystko jest zasobem W pozostałym stylu architektonicznym Dane i funkcjonalności są uważane za zasoby i są dostępne za pomocą Uniform Resource Identifiers( Uri), zazwyczaj linków w sieci.
• Zasada 2: Każdy Zasób is Identified by a Unique Identifier (URI)
• zasada 3: używaj prostych i jednolitych interfejsów
• Zasada 4: komunikacja odbywa się przez reprezentację
• Zasada 5: BYĆ Bezpaństwowcem

Widzę kilka odpowiedzi, które mówią, że umieszczenie wszystkiego o user 123 w zasobie "/ user/123" jest spokojne.

Więc jeśli twoja ścieżka "/user / 123" jest zakodowana na twardo na kliencie, nie jest naprawdę spokojna. Dobre wykorzystanie HTTP, może, może nie. Ale nie spokojny. Musi pochodzić z hipertekstu.

Odpowiedź jest bardzo prosta, istnieje rozprawa napisana przez Roya Fieldinga.]1 w rozprawie tej określa zasady reszty. Jeśli aplikacja spełnia wszystkie te zasady, to jest to aplikacja REST.

Termin RESTful powstał, ponieważ ppl wyczerpało słowo REST, nazywając swoją aplikację non-REST jako REST.Później termin "odpoczynek" również został wyczerpany. Obecnie mówimy o Web API i Hypermedia API , ponieważ większość tzw. aplikacji REST nie spełniała HATEOAS części jednolitego ograniczenia interfejsu.

Pozostałe ograniczenia są następujące:

1. Architektura klient-serwer

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

2. Bezpaństwowa komunikacja

   Więc serwer nie utrzymuje Stanów klientów. Oznacza to, że nie można korzystać z magazynu sesji po stronie serwera i musisz uwierzytelnić każde żądanie. Twoi klienci mogą wysyłać podstawowe nagłówki auth za pośrednictwem szyfrowanego połączenia. (Przy dużych aplikacjach trudno jest utrzymać wiele sesji.)

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

   Więc nie musisz ciągle obsługiwać tych samych próśb.

4. Jednolity interfejs jako wspólna umowa między Klientem a serwerem

   Umowa między Klientem a serwerem nie jest utrzymywana przez serwer. Innymi słowy klient musi być oddzielony od realizacji usługi. Stan ten można osiągnąć za pomocą standardowych rozwiązań, takich jak Standard IRI (URI) do identyfikacji zasobów, standard HTTP do wymiany wiadomości, standardowe typy MIME do opisu formatu serializacji ciała, metadane (ewentualnie vocabs RDF, mikroformaty itp.), aby opisać semantykę różnych części ciała komunikatu. Aby oddzielić strukturę IRI od klienta, musisz wysłać hiperłącza do klientów w hypermedia formaty takie jak (HTML, JSON-LD, HAL, itp.). Tak więc klient może użyć metadanych (ewentualnie relacji łącza, vocabs RDF) przypisanych do hiperłączy, aby poruszać się po maszynie 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 wysyłanych przez sklep internetowy. Sprawdzając linki daje jeden opisany z http://schema.org/OrderAction . klient zna schema.org vocab, 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 na wynik z odpowiednim nagłówkiem statusu HTTP, na przykład 201 - created przez successful. Do opisywania wiadomości ze szczegółowymi metadanymi standardowym rozwiązaniem jest użycie formatu RDF, na przykład JSON-LD z VOCABEM REST, na przykład Hydra i vocabami specyficznymi dla domeny, takimi jak schema.org lub jakiekolwiek inne połączone dane vocab i może Niestandardowy specyficzny vocab aplikacji w razie potrzeby. Teraz nie jest to łatwe, dlatego większość ppl używa HAL i innych prostych formatów, które zwykle zapewniają tylko REST vocab, ale bez wsparcia powiązanych danych.

5. Zbuduj warstwowy system, aby zwiększyć skalowalność

   System REST składa się z warstw hierarchicznych. Każda warstwa zawiera komponenty, które korzystają z usług komponentów, które znajdują się w następnej warstwie poniżej. Dzięki temu można bez wysiłku dodawać nowe warstwy i Komponenty.

   Na przykład istnieje warstwa klienta, która zawiera klientów, a poniżej znajduje się warstwa usługi, która zawiera jedną 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 load balancer i tak dalej... Kod klienta i Kod usługi nie ulegną zmianie.

6. Kod na żądanie rozszerzenia funkcjonalności klienta

   To ograniczenie jest opcjonalne. Na przykład możesz wysłać do klienta parser dla określonego typu nośnika i tak dalej... Aby to zrobić, możesz potrzebować standardowego systemu ładowania wtyczek w kliencie lub twój Klient zostanie połączony z rozwiązaniem ładowania wtyczek.

RESTful (Representational state transfer) programowanie API to pisanie aplikacji internetowych w dowolnym języku programowania według 5 podstawowych zasad stylu architektonicznego:

1. zasób (dane, informacje).
2. unikalny identyfikator globalny (wszystkie zasoby są unikalne identyfikowane przez URI).
3. Uniform interface - Użyj prostego i standardowego interfejsu (HTTP).
4. Reprezentacja-cała komunikacja odbywa się przez reprezentacja (np. XML/JSON )
5. Stateless (każde żądanie odbywa się w całkowitej izolacji, łatwiej jest buforować i równoważyć obciążenie),

Innymi słowy piszesz proste aplikacje sieciowe punkt-punkt przez HTTP, które używają czasowników takich jak GET, POST, PUT lub DELETE poprzez implementację architektury RESTful, która proponuje standaryzację interfejsu każdego" Zasobu". To nic, że korzystanie z aktualnych funkcji sieci w prosty i skuteczny sposób (bardzo udana, sprawdzona i rozproszona Architektura). Jest alternatywą dla bardziej złożonych mechanizmów, takich jak SOAP, CORBA i RPC .

Programowanie RESTful jest zgodne z projektowaniem architektury WWW i, jeśli jest prawidłowo wdrożone, pozwala w pełni wykorzystać możliwości skalowalnej infrastruktury internetowej.

Gdybym miał zredukować oryginalną rozprawę o odpoczynku do zaledwie 3 krótkich zdań, myślę, że następujące ujęcia jego istoty:

1. zasoby są wymagane przez adresy URL.
2. protokoły są ograniczone do tego, co można komunikować się za pomocą adresów URL.
3. metadane są przekazywane jako pary nazwa-wartość(dane post i parametry ciągu zapytania).

Po tym, łatwo wpaść w dyskusje na temat adaptacji, konwencji kodowania i najlepszych praktyk.

Co ciekawe, tam nie ma wzmianki o HTTP POST, GET, DELETE, lub umieścić operacji w rozprawie. To musi być czyjaś późniejsza interpretacja "najlepszej praktyki" dla "jednolitego interfejsu".

Jeśli chodzi o Usługi internetowe, wydaje się, że potrzebujemy jakiegoś sposobu odróżnienia architektur opartych na WSDL i SOAP, które dodają znaczny narzut i prawdopodobnie dużo niepotrzebnej złożoności interfejsowi. Wymagają one również dodatkowych frameworków i narzędzi programistycznych w celu wdrożenia. Nie wiem czy odpoczynek jest najlepszy termin do rozróżnienia między interfejsami zdroworozsądkowymi a zbyt zaprojektowanymi interfejsami, takimi jak WSDL i SOAP. Ale potrzebujemy czegoś.

Oto mój podstawowy zarys odpoczynku. Starałem się zademonstrować myślenie stojące za każdym z komponentów w architekturze RESTful, aby zrozumienie koncepcji było bardziej intuicyjne. Mam nadzieję, że to pomoże demystify odpoczynku dla niektórych ludzi!

REST (Representational State Transfer) jest architekturą projektową, która określa sposób projektowania i adresowania zasobów sieciowych (tj. węzłów, które dzielą się informacjami). Ogólnie rzecz biorąc, Architektura RESTful sprawia, że klient (żądający maszyna) i serwer (maszyna odpowiadająca) może zażądać odczytu, zapisu i aktualizacji danych bez konieczności wiedzy klienta o działaniu serwera i serwer może przekazać je z powrotem bez potrzeby wiedzy o kliencie. Spoko...ale jak to zrobić w praktyce?

• Najbardziej oczywistym wymogiem jest to, że musi istnieć jakiś uniwersalny język, aby serwer mógł powiedzieć klientowi, co próbuje zrobić z żądaniem i aby serwer mógł odpowiedz.

• Ale aby znaleźć dany zasób, a następnie powiedzieć klientowi, gdzie ten zasób żyje, musi istnieć uniwersalny sposób Wskazywania zasobów. To tutaj pojawiają się Uniwersalne identyfikatory zasobów (URI); są one w zasadzie unikalnymi adresami do wyszukiwania zasobów.

Ale reszta architektury nie kończy się na tym! Chociaż powyższe spełnia podstawowe potrzeby tego, czego chcemy, chcemy również mieć architekturę, która obsługuje duży ruch, ponieważ każdy dany serwer zwykle obsługuje odpowiedzi od wielu klientów. Dlatego nie chcemy przytłaczać serwera poprzez zapamiętywanie informacji 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ć niczego o poprzednich żądaniach (poprzednich Stanach interakcji klient-serwer), aby odpowiedzieć na nowe żądanie. Oznacza to, że chcemy nasze interakcje są bezpaństwowe.

• Aby jeszcze bardziej odciążyć nasz serwer od ponownego wykonywania obliczeń, które zostały już niedawno wykonane dla danego klienta, REST umożliwia również buforowanie. Zasadniczo buforowanie oznacza zrobienie migawki początkowej odpowiedzi dostarczonej klientowi. Jeśli klient ponownie wyśle to samo żądanie, serwer może dostarczyć klientowi migawkę, a nie ponowić wszystkie obliczenia, które były konieczne do utworzenia początkowej odpowiedzi. Jednakże, ponieważ jest to migawka, jeśli migawka nie wygasła-serwer ustawia z góry czas wygaśnięcia-a odpowiedź została zaktualizowana od początkowego bufora (tzn. żądanie dałoby inną odpowiedź niż buforowana odpowiedź), klient nie zobaczy aktualizacji, dopóki bufor nie wygaśnie (lub bufor zostanie wyczyszczony) i odpowiedź zostanie ponownie renderowana od zera.

• Ostatnią rzeczą, którą często będziesz tutaj o architekturach odpoczynku, jest to, że są one warstwowe. Mamy faktycznie już pośrednio 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 współdziała tylko z sąsiednimi warstwami. Tak więc w naszej dyskusji warstwa kliencka współdziała z naszą warstwą serwerową (i odwrotnie), ale mogą istnieć inne warstwy serwerowe, które pomagają serwerowi głównemu przetwarzać żądanie, z którym Klient nie komunikuje się bezpośrednio. Raczej serwer przekazuje żądanie jako konieczne.

REST jest wzorcem architektonicznym i stylem pisania aplikacji rozproszonych. Nie jest to styl programowania w wąskim znaczeniu.

Mówienie, że używasz stylu REST jest podobne do mówienia, że zbudowałeś dom w określonym stylu: na przykład Tudor lub wiktoriański. Zarówno REST jako styl oprogramowania, jak I Tudor lub wiktoriański jako styl domu mogą być zdefiniowane przez cechy i ograniczenia, które je tworzą. Na przykład REST musi mieć oddzielenie od serwera klienta, gdzie wiadomości są samokrytyka. Domy w stylu Tudor mają nakładające się szczyty i dachy, które są stromo spadziste z przodem zwróconymi szczytami. Możesz przeczytać rozprawę Roya, aby dowiedzieć się więcej o ograniczeniach i cechach, które składają się na odpoczynek.

Odpoczynek w przeciwieństwie do domowych stylów miał trudny czas, będąc konsekwentnie i praktycznie stosowane. To mogło być zamierzone. Pozostawienie jego faktycznej realizacji projektantowi. Więc możesz robić to, co chcesz, tak długo, jak spełniasz ograniczenia określone w tworzysz systemy odpoczynku.

Bonus:

Cała sieć jest oparta na REST (lub REST był oparty na sieci). Dlatego jako programista stron internetowych możesz chcieć o tym wiedzieć, chociaż nie jest konieczne pisanie dobrych aplikacji internetowych.

Myślę, że punktem restful jest rozdzielenie stanu na wyższą warstwę przy wykorzystaniu Internetu (protokołu) jako bezstanowej warstwy transportowej . Większość innych podejść miesza rzeczy.

To najlepsze praktyczne podejście do podstawowych zmian w programowaniu w erze Internetu. Jeśli chodzi o podstawowe zmiany, Erik Meijer prowadzi tutaj dyskusję: http://www.infoq.com/interviews/erik-meijer-programming-language-design-effects-purity#view_93197. Podsumowuje je jako pięć efektów i przedstawia rozwiązanie projektując rozwiązanie w języku programowania. Rozwiązanie to można również osiągnąć na poziomie platformy lub systemu, niezależnie od języka. Restful może być postrzegany jako jedno z rozwiązań, które odniosło wielki sukces w obecnej praktyce.

Z restful style, można uzyskać i manipulować stan aplikacja przez nierzetelny internet. Jeśli bieżąca operacja nie powiedzie się, aby uzyskać poprawny i aktualny stan, potrzebuje podstawy zerowej walidacji, aby pomóc aplikacji w kontynuowaniu. Jeśli nie manipuluje stanem, zwykle używa wielu etapów potwierdzenia, aby utrzymać poprawność. W tym sensie rest sam w sobie nie jest rozwiązaniem całościowym, potrzebuje funkcji w innej części stosu aplikacji webowych, aby wspierać jego działanie.

Biorąc pod uwagę ten punkt widzenia, styl reszta jest nie jest związany z Internetem lub aplikacją internetową. Jest to podstawowe rozwiązanie wielu sytuacji programistycznych. Nie jest to również proste, po prostu sprawia, że interfejs jest naprawdę prosty i radzi sobie z innymi technologiami zadziwiająco dobrze.

Tylko moje 2c.

Edit: dwa ważniejsze aspekty:

• Bezpaństwowość wprowadza w błąd. Chodzi o API restful, a nie o aplikację czy system. System musi być Stanowy. Restful design polega na zaprojektowaniu stateful system oparty na stateless API. Niektóre cytaty z innego QA :

  • REST, działa na reprezentacjach zasobów, z których każda identyfikowana jest przez adres URL. Zazwyczaj nie są to obiekty danych, lecz abstrakcje obiektów złożonych .
  • REST oznacza "reprezentacyjny transfer stanu", co oznacza, że chodzi o komunikowanie i modyfikowanie stanu jakiegoś zasobu w systemie.

• Idempotencja: Na często pomijaną częścią odpoczynku jest idempotencja większości czasowników. To prowadzi do solidnych systemów i mniejszej współzależności dokładnych interpretacji semantyki .

Jest to zdumiewająco długa "dyskusja", a jednocześnie dość myląca, co najmniej.

IMO:

1) nie ma czegoś takiego jak spokojny program, bez dużego jointa i dużo piwa:)

2) Reprezentacyjny Transfer stanu (REST) to styl architektoniczny określony w dysertacji Roya Fieldinga[9]. Ma wiele ograniczeń. Jeśli Twój serwis / klient szanuje tych, To jest spokojny.To jest to.

Można podsumować (znacznie) ograniczenia do:

• bezpaństwowa komunikacja
• respect http specs (jeśli HTTP jest używany)
• wyraźnie komunikuje przekazywane Formaty treści
• użyj hypermedia jako silnik stanu aplikacji

Jest jeszcze jeden Bardzo dobry post , który ładnie wszystko wyjaśnia.

Wiele odpowiedzi kopiuje / wkleja poprawne informacje mieszając je i dodając pewne zamieszanie. Ludzie mówią tu o poziomach, o spokojnych URI(jest nie coś takiego!), zastosuj metody HTTP GET, POST,PUT ... Odpoczynek nie chodzi o to czy nie tylko o to.

Na przykład linki-miło jest mieć pięknie wyglądające API, ale na końcu klient / serwer nie dba o linki, które dostajesz/wysyłasz, liczy się treść.

W końcu każdy klient RESTful powinien być w stanie korzystać z dowolnej usługi RESTful, o ile znany jest format treści.

REST oznacza Reprezentacyjny transfer stanu .

Opiera się na bezstanowym, kliencie-serwerze, buforowalnym protokole komunikacyjnym -- i praktycznie we wszystkich przypadkach używany jest protokół HTTP.

REST jest często używany w aplikacjach mobilnych, portalach społecznościowych, narzędziach mashup i zautomatyzowanych procesach biznesowych. Styl REST podkreśla, że interakcje między klientami i usługami są wzmocnione przez ograniczoną liczbę operacji (czasowników). Elastyczność zapewnia się poprzez przypisanie zasobów (rzeczowników) własnych unikalnych uniwersalnych wskaźników zasobów (Uri).

Wstęp o odpoczynku

rozmowa to coś więcej niż tylko wymiana informacji . Protokół jest tak skonstruowany, że nie trzeba rozmawiać. Każda ze stron wie, jakie jest jej zadanie, ponieważ jest ono określone w protokole. Protokoły pozwalają na czystą wymianę informacji kosztem jakichkolwiek 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 dwa razy zadać to samo pytanie i uzyskaj dwie różne odpowiedzi, ponieważ stan drugiej strony mógł się zmienić w międzyczasie. mówienie jest spokojną architekturą . Teza Fieldinga określa architekturę, którą należy podążać, jeśli chcemy, aby maszyny mogły ze sobą rozmawiać, a nie po prostu komunikować się.

Nie ma takiego pojęcia jak" RESTful programming " per se. Byłoby lepiej nazwać RESTful paradygmat lub nawet lepszą architekturę RESTful. Nie jest to język programowania. To paradygmat.

Z Wikipedii :

W informatyce reprezentacyjny transfer stanu (REST) jest styl architektoniczny używany do tworzenia stron internetowych.

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

1. ustrukturyzowane adresy URL i metody Http / czasowniki nie są definicją restful programming.
2. JSON nie jest programowaniem restful
Programowanie RESTful nie jest dla API

Definiuję programowanie restful jako

Aplikacja jest restful, jeśli udostępnia zasoby (będące kombinacją danych + przejść stanu kontrolki) w typie nośnika, który klient rozumie

Aby być spokojnym programistą musisz próbować budować aplikacje, które pozwalają aktorom robić rzeczy. Nie tylko ujawnienie bazy danych.

Kontrola przejścia stanu ma sens tylko wtedy, gdy klient i serwer zgadzają się na reprezentację typu nośnika zasobu. W przeciwnym razie nie ma sposobu, aby wiedzieć, co jest kontrolą, a co nie i jak wykonać kontrolę. IE gdyby przeglądarki nie znały tagów w html to nie byłoby nic aby przejść do stanu przejścia w przeglądarce.

Nie chcę się promować, ale rozszerzam te pomysły do głębi w mojej wypowiedzi http://techblog.bodybuilding.com/2016/01/video-what-is-restful-200.html .

REST = = = analogia HTTP nie jest poprawna, dopóki nie podkreślisz, że "musi" być HATEOAS napędzany.

Roy sam to wyczyścił tutaj .

API REST powinno być wprowadzone bez uprzedniej wiedzy poza początkowym URI (Zakładka) i zestaw standardowych typów mediów, które są odpowiednie dla docelowej grupy odbiorców (tj. oczekuje się, że zostaną zrozumiane przez każdego klienta, który może korzystać z API). Od tego momentu wszystkie przejścia stanu aplikacji muszą być sterowane poprzez wybór przez Klienta dostarczonych przez serwer wyborów, które są obecne w otrzymanych reprezentacjach lub sugerowane przez manipulację użytkownika tymi reprezentacjami. Przejścia mogą być określone (lub ograniczone) przez znajomość przez Klienta typów mediów i mechanizmów komunikacji z zasobami, z których oba mogą być ulepszane w locie (np. kod na żądanie).

[awaria tutaj implikuje, że informacja poza pasmem napędza interakcję zamiast hipertekstu.]

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

W architekturze opartej na REST, wszystko jest zasobem(użytkownicy, zamówienia, Komentarze). Dostęp do zasobu odbywa się poprzez wspólny interfejs oparty 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 uzyskać dostęp i modyfikować Odpoczynek zasoby.

Każdy zasób powinien obsługiwać wspólne operacje HTTP. Zasoby identyfikowane są za pomocą identyfikatorów globalnych (które zazwyczaj są identyfikatorami Uri).

REST pozwala na to, że zasoby mają różne reprezentacje, np. tekst, XML, JSON itp. Klient REST może poprosić o konkretną reprezentację poprzez protokół HTTP (negocjacje treści).

Metody HTTP:

Metody PUT, GET, POST i DELETE są typowe dla architektur opartych na REST. Na poniższa tabela zawiera wyjaśnienie tych operacji.

• GET definiuje dostęp do odczytu zasobu bez efektów ubocznych. Zasób nigdy nie jest zmieniany poprzez żądanie GET, np. żądanie nie ma skutków ubocznych (idempotent).
• PUT tworzy nowy zasób. Musi być również idempotentny.
• DELETE usuwa zasoby. Operacje są idempotentne. Mogą być powtarzane bez prowadzenia do różnych wyników.
• Po aktualizacji istniejącego zasobu lub tworzy nowy zasób.

Punktem odpoczynku jest to, że jeśli zgodzimy się używać wspólnego języka dla podstawowych operacji (czasowniki http), infrastruktura może być skonfigurowana tak, aby je rozumieć i optymalizować odpowiednio, na przykład poprzez wykorzystanie nagłówków buforowania do implementacji buforowania na wszystkich poziomach.

Przy prawidłowo zaimplementowanej operacji restful GET, nie powinno mieć znaczenia, czy informacje pochodzą z bazy danych serwera, memcache serwera, CDN, pamięci podręcznej proxy, pamięci podręcznej przeglądarki lub lokalnej przeglądarki magazyn. Można użyć na czczo, najprościej dostępnego, aktualnego źródła.

Stwierdzenie, że Rest jest tylko zmianą składniową z użycia żądań GET z parametrem action na użycie dostępnych czasowników http sprawia, że wygląda to tak, jakby nie miało żadnych korzyści i jest czysto kosmetyczne. Chodzi o to, aby używać języka, który może być zrozumiały i zoptymalizowany przez każdą część łańcucha. Jeśli Twoja operacja GET ma działanie z efektami ubocznymi, musisz pominąć wszystkie buforowanie HTTP lub skończysz z niespójnym wyniki.

REST definiuje 6 ograniczeń architektonicznych, które sprawiają, że każda usługa sieciowa – A true RESTful API .

1. jednolity interfejs
2. Klient-Serwer
3. Stateless
4. Cacheable
5. Układ warstwowy
6. Kod na żądanie (opcjonalnie)

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

Czym jest testowanie API ?

Testowanie API wykorzystuje Programowanie do wysyłania wywołań do API i uzyskiwania wydajności. Testuje on badany segment jako czarną skrzynkę. Celem testów API jest potwierdzenie poprawnego wykonania i błędnego potraktowania części poprzedzającej jego koordynację z aplikacją.

REST API

REST: Reprezentacyjny Transfer stanu.

• jest to układ funkcji, na których testery wykonują prośby i otrzymywanie odpowiedzi. W REST API interakcje są dokonywane za pośrednictwem protokołu HTTP.
• REST umożliwia również komunikację między komputerami ze sobą poprzez 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.
• komunikaty REST często przyjmują formę w postaci XML lub JavaScript Object Notation (JSON).

4 powszechnie używane API Metody:-

1. GET: - zapewnia dostęp tylko do odczytu do zasobu.
2. POST: - służy do tworzenia lub aktualizacji nowego zasobu.
3. PUT – - służy do aktualizacji lub zastąpienia istniejącego zasobu lub utworzenia nowego zasobu.
4. DELETE: - służy do usunięcia zasobu.

Kroki do ręcznego testowania API:-

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

1. Install POSTMAN (Chrome) / REST (Firefox) plugin
2. wprowadź adres URL API
3. Wybierz metodę REST
4. Select content-Header
5. Enter Request JSON (POST)
6. kliknij Wyślij
7. zwróci odpowiedź wyjścia

Kroki do automatyzacji REST API

Jest to bardzo mniej wspominane wszędzie, ale Model dojrzałości Richardsona jest jedną z najlepszych metod, aby właściwie ocenić, jak Restful jest czyjeś API. Więcej na ten temat tutaj:

Model dojrzałości Richardsona

REST to styl architektury oprogramowania systemów rozproszonych (takich jak WWW), można sobie wyobrazić, że jest to dobrze zaprojektowana aplikacja internetowa reguły: grupa stron internetowych (wirtualna maszyna stanów), w której hiperłącze klikając link (przejście stanu), wynikiem jest Następna strona internetowa (co oznacza Następny stan aplikacji).

REST opisuje system sieciowy składa się z trzech części:

1. elementy danych( resource, resource identifier, reprezentacja)
2. connectors (client, server, cache, resolver, tunnel)
3. komponenty (origin server, gateway, proxy, user agent)

Reszta ściśle spełnia następujące warunki:

1. Status funkcjonalności aplikacji jest podzielony na zasoby
2. każdy zasób używany jako składnia pozycjonowania hiperłączy (tj. w URI WWW)
3. wszystkie zasoby współdzielą jednolity interfejs między Klientem ze stanem przejścia zasobów, w tym:
   1. ograniczony zestaw dobrze zdefiniowanych operacji (np. w HTTP GET / POST / PUT / DELETE)
   2. ograniczony zestaw formatów treści, które mogą zawierać kod wykonywalny (np. w WWW Javascript)