Czy możesz wyjaśnić pojęcie Web RESTful?

Question

Poszukuję jasnych i zwięzłych wyjaśnień tego pojęcia.

Answer 1

spokojny aplikacja jest aplikacją, która odsłania swój stan i funkcjonalność jako zbiór zasobów, które klienci mogą manipulować i jest zgodny z określonym zbiorem zasad:

• Wszystkie zasoby są jednoznacznie adresowalny, zwykle przez URI ; można jednak również zastosować inne adresowanie.
• Wszystkimi zasobami można manipulować za pomocą zestawu znanych działań, zwykle CRUD (tworzenie, odczytywanie, aktualizacja, usuwanie), najczęściej reprezentowanego przez HTTP POST, GET, PUT i DELETE; może to być inny zestaw lub podzbiór - na przykład niektóre ograniczenia implementacji, które ustawiono tylko do odczytu i modyfikacji (GET i PUT), na przykład
• Dane dla wszystkich zasobów są przesyłane za pośrednictwem dowolnej ograniczonej liczby dobrze znane reprezentacje, zwykle HTML, XML lub JSON;
• Komunikacja między klientem a aplikacją odbywa się za pośrednictwem protokołu bezstanowego, który pozwala wielu wielowarstwowym pośrednikom, którzy mogą przekierowywać i buforować pakiety zapytań i odpowiedzi w przejrzysty sposób dla klienta i aplikacji.

The 01 Scottish, wskazał więcej szczegółów na temat pochodzenia REST, szczegółowych zasad, przykładów i tak dalej.

Answer 2

Oznacza to używanie nazw w celu identyfikacji zarówno poleceń, jak i parametrów.

Zamiast nazw będących zwykłymi uchwytami lub monikerami, sama nazwa zawiera informacje. W szczególności informacje o żądanych żądaniach, parametry żądania itd.

Nazwy nie są "rootami", ale raczej czynnościami plus dane wejściowe.

Answer 3

Szczerze mówiąc, odpowiedź zależy od kontekstu. REST i RESTful mają znaczenie w zależności od używanego języka lub architektury lub tego, co próbujesz osiągnąć. Ponieważ oznaczyłeś swoje pytanie jako "usługi internetowe", odpowiem w kontekście usług internetowych RESTful, które nadal stanowią szeroką kategorię.

Usługi sieciowe RESTful mogą oznaczać wszystko, począwszy od ścisłej interpretacji REST, gdzie wszystkie działania są wykonywane w ściśle "restrykcyjny" sposób, do protokołu, który jest zwykły XML, co oznacza, że ​​nie jest to SOAP ani XMLRPC. W tym drugim przypadku jest to mylące: taki protokół REST jest naprawdę "plain old XML" (or "POX") protocol. Podczas gdy protokoły REST zwykle używają XML i jako takie są protokołami POX, nie musi tak być, a odwrotność nie jest prawdą (tylko dlatego, że protokół używa XML nie czyni go restupem).

Bez zbędnych ceregieli, prawdziwie RESTful API składa się z działań podejmowanych na obiektach, reprezentowanych przez zastosowaną metodę HTTP i URL tego obiektu. Działania dotyczą danych, a nie tego, co robi metoda. Na przykład akcje CRUD (tworzenie, odczytywanie, aktualizowanie i usuwanie) mogą mapować do określonego zestawu adresów URL i działań. Powiedzmy, że wchodzisz w interakcję z interfejsem API zdjęć.

• Aby utworzyć zdjęcie, należy wysłać dane za pośrednictwem żądania POST do/photos. Dzięki niemu dowiesz się, gdzie zdjęcie znajduje się w nagłówku lokalizacji, np./photos/12345
• Aby wyświetlić zdjęcie, można użyć GET/photos/12345
• Aby zaktualizować zdjęcie, należy wysłać dane za pomocą żądania PUT do/photos/12345.
• Aby usunąć zdjęcie, można użyć polecenia USUŃ/ZDJĘĆ/12345
• Aby uzyskać listę zdjęć, można użyć funkcji GET/photos.

Można zaimplementować inne działania, takie jak możliwość kopiowania zdjęć za pomocą żądania COPY.

W ten sposób, metoda HTTP używasz mapy bezpośrednio z zamiarem rozmowy, zamiast wysyłać działanie chcesz wziąć jako część API. Aby się przeciwstawić, RESTful API może używać znacznie więcej adresów URL i używać tylko akcji GET i POST. Tak więc, w tym przykładzie można zobaczyć:

• Aby utworzyć zdjęcie, wyślij pocztą na adres/zdjęć/tworzyć
• Aby wyświetlić zdjęcie, wyślij dostać się do/zdjęcia/view/12345
• Aby zaktualizować zdjęcie, wyślij POST do/photos/update/12345
• Aby usunąć zdjęcie, wyślij GET do/photos/delete/12345
• Aby otrzymać listę zdjęć, wyślij GET do/photos/lista

będziesz zauważ, że w tym przypadku adresy URL są różne, a metody wybierane są tylko z technicznego punktu widzenia: do wysyłania danych, musisz użyć POST, podczas gdy wszystkie inne żądania używają GET.

Answer 4

Zaledwie kilka punktów:

• spokojny nie zależą ramach którego używasz. To zależy od stylu architektonicznego, który opisuje. Jeśli nie stosujesz się do ograniczeń, nie jesteś REST. Ograniczenia są zdefiniowane na pół strony rozdziału 5 dokumentu Roy Fielding, zachęcam do przeczytania go.
• Identyfikator jest nieprzejrzysty i nie Cary żadnych informacji poza identyfikacją zasobu. To nmae, a nie dane wejściowe, tylko nazwy. jeśli chodzi o klienta, nie ma żadnej logiki ani wartości poza wiedzą, jak budować zapytania z tagu formularza. Jeśli twój klient tworzy własne identyfikatory URI przy użyciu schematu, który zdecydowałeś z góry, nie jesteś spokojny.
• Użycie lub użycie wszystkich czasowników http nie jest tak naprawdę ograniczeniem i całkowicie dopuszczalne jest projektowanie architektury obsługującej tylko POST.
• Buforowanie, wysokie oddzielenie, brak stanu sesji i warstwowa architektura to punkty, o których niewiele mówi się, ale które są najważniejsze dla powodzenia architektury REST.

Jeśli nie spędzasz większość czasu na tworzeniu swojego formatu dokumentu, prawdopodobnie nie robisz REST.

Answer 5

Najlepszym wyjaśnieniem znalazłem jest w tym .

Answer 6

Najbardziej nauczyłem się z lektury artykułów opublikowanych na stronie InfoQ.com: http://www.infoq.com/rest oraz książki usługi RESTful Web Services (http://oreilly.com/catalog/9780596529260/).

./alex

Zastrzeżenie: Jestem związane z InfoQ.com, ale to zalecenie na podstawie własnego doświadczenia uczenia się.

Answer 7

REST tytułem przykładu:

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

Serwer odpowiada:

200 OK 
Location: /user/123 

W przyszłości, będzie można pobrać informacji o użytkowniku:

GET /user/123 

Serwer odpowiada:

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

Aby zaktualizować:

PUT /user/123 
fname=Johnny