Czego nie rozumiem w odpoczynku?

Buduję framework i chcę, aby deweloperzy, którzy budują z nim, mieli możliwość zezwalania częściom niego zarówno na udostępnianie danych innym witrynom, jak i zezwalanie innym witrynom na dodawanie/edycję / usuwanie danych.

Na przykład, jeśli ktoś tworzy stronę z recenzjami książek, autorami, cytatami, przykładami kodu, komentarzami itp. deweloper może np. uczynić "recenzje książek" tylko do odczytu dla innych witryn i "komentarze" czytelnymi dla innych witryn i nadającymi się do zapisu dla niektórych witryn/użytkowników. Chodzi o to, aby wykorzystać framework do twórz aplikacje, które można łatwo łączyć z innymi aplikacjami.

Wyobrażam sobie włączenie wszystkich interakcji ze stroną przez POST I GET, które wyglądałyby mniej więcej tak:

  • /książki.php?category = ruby (zwraca kolekcję XML książek o Rubim)
  • /książki.php?id=23 (zwraca XML dla określonego książka)
  • /książki.php?action=add&title = AdvancedRuby&description=....& securityId=923847203487
  • /książki.php?action=delete&id=342&securityId=923847203487

Inne aplikacje mogą również "odkryć i konsumować" to, co dana strona ma do zaoferowania, robiąc to:

  • /odkryj.php (zwraca XML wszystkich dostępnych klas i akcji publicznych)

Naprawdę to wszystko, czego potrzebuję, aby framework był sposobem na programistów, aby szybko tworzyć luźno połączone witryny.

Chcę wiedzieć, zanim zacznę to implementować, czy są znaczące / interesujące części reszty, których jeszcze nie rozumiem, które powinienem wbudować w framework, np.:

  • reszta wymaga GET, POST, PUT i DELETE. Po co mi "PUT" I "DELETE"? Czy blokuję się przed korzystaniem z jakiegoś standardu, jeśli ich nie używam?
  • moje " odkrycie.php " funkcje plików podobnie jak plik WSDL w serwisach internetowych. Dziwię się w opisach wypoczynku wydaje się, że nie ma standaryzowanego sposobu odkrywania usług, które oferuje serwis odpoczynku, czy jest?
  • jeśli strona klienta spróbuje np. dodać książkę do strony serwera i nie otrzyma żadnej odpowiedzi" sukces", po prostu spróbuje ponownie, dopóki nie otrzyma odpowiedzi. Strona serwera po prostu nie dodałaby tej samej książki dwa razy. To jest moje zrozumienie integralności danych w spoczynku, czy jest coś więcej niż to?

  • W końcu chcę mieć wiele stron, które mają te same bogate klasy, np. "BookReview", aby Strona klienta mogła wykonać kod taki jak ten:

    $bookReview = new BookReview (" http://www.example.com/books.php?id=23 "); $book- > informAuthor ("komentarz do recenzji książki został opublikowany na naszej stronie...");

A strona serwera wyśle e-mail do autora tej recenzji. Jest to typ typu interakcja elementem filozofii RESTful czy REST jest po prostu wymianą danych przez XML, JSON?

Author: Oli, 2008-12-05
Source

7 answers

Czy blokuję się przed korzystaniem z jakiegoś standardu, jeśli ich nie używam?

Ty sam blokujesz się od standardu HTTP. Oczywiście możesz użyć parametrów GET, aby zrobić to samo. To po prostu nie odpoczynek, ale coś w stylu RPC.

Czy mogę zaproponować książkęRESTful Web Services autorstwa Leonarda Richardsona i sama Ruby? Jest to dość zabawne czytać i pokazuje różnice między różnymi podejściami.

Aby odpowiedzieć na twoje pytania w nieco więcej szczegółów: to do ciebie należy decyzja, w którą stronę pójdziesz. W teorii można zrobić wszystkie te same rzeczy zarówno z RESTful i RPC-podobne podejścia. Z RESTful używasz podkładowego protokołu HTTP jako protokołu . Z RPC używasz HTTP tylko jako środka transportu i ukrywasz zlecenia pracy gdzieś w transportowanych danych. To prowadzi do (nieodwzajemnionej) napowietrzności.

Wystarczy spojrzeć na dwa swoje przykłady:

  • /książki.php?action=add&title = AdvancedRuby&description=....& securityId=923847203487
  • /książki.php?action=delete&id=342&securityId=923847203487
    • jest POST I PUT lub DELETE, dlaczego action = add i action=delete?
    • jest uwierzytelnianie HTTP. Po co wymyślać-być może mniej bezpieczne-securityId?
    • BTW: nie powinieneś zezwalać na zmiany danych poprzez GET. To po prostu coś, czego nie powinno się robić (inny temat, chociaż ;))
 23
Author: BlaM,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-12-05 09:35:17

Proponuję przeczytać ten post Roya Fieldinga.

Podświetlenie:

  • Interfejs REST API powinien poświęcić prawie cały swój opisowy wysiłek na zdefiniowanie typów mediów używanych do reprezentowania zasobów i napędzania stanu aplikacji, lub na zdefiniowanie rozszerzonych nazw relacji i / lub znaczników z włączonym hipertekstem dla istniejących standardowych typów mediów. Każdy wysiłek poświęcony na opisanie, jakie metody stosować na jakie interesujące Uri powinien być całkowicie zdefiniowany w zakresie reguły przetwarzania dla typu nośnika (i, w większości przypadków, już zdefiniowanego przez istniejące typy nośników). [Awaria sugeruje tutaj, że informacje spoza pasma napędzają interakcję zamiast hipertekstu.]

  • API REST nie może definiować stałych nazw zasobów ani hierarchii (oczywiste połączenie klienta i serwera). Serwery muszą mieć swobodę kontrolowania własnej przestrzeni nazw. Zamiast tego pozwól serwerom instruować klientów, jak konstruować odpowiednie Uri, np. w formularzach HTML i Szablony URI, definiując te instrukcje w obrębie typów nośników i relacji łącza. [Awaria implikuje, że klienci przyjmują strukturę zasobów ze względu na informacje poza pasmem, takie jak Standard specyficzny dla domeny, który jest zorientowanym na dane odpowiednikiem funkcjonalnego sprzężenia RPC].

Z pewnością możesz odnieść sukces używając podejścia podobnego do RPC, które opisujesz i jest łatwiejsze do zrozumienia niż "właściwe API REST". Najbardziej niezrozumianym aspektem odpoczynku jest to, że po zdefiniowany, powinien automatycznie działać, nie powinieneś definiować przejdź do tego URI używając tej metody, aby uzyskać odpowiedź, która powinna być sugerowana przez typy mediów, które dostarczasz, plus sposób, aby poinformować klientów, gdzie znaleźć odpowiednie zasoby.

 8
Author: Vinko Vrsalovic,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-12-05 09:41:49

Z RestWiki :

  • GET to an identifier oznacza "Daj mi kopię swoich informacji w określonym formacie dokumentu".
  • PUT to that identifier oznacza "Zamień swoje informacje na moje".
  • POST dodaje informacje, a
  • Usuń eliminuje informacje.

Mając to na uwadze, zastosowanie go do aplikacji powinno być dość proste.

 4
Author: Svante,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-12-05 10:45:15

Z frameworkiem Restlet dokładnie staraliśmy się zapewnić ten poziom abstrakcji powyżej szczegółów HTTP i uczynić koncepcje REST bardziej konkretnymi (wiele z nich ma dopasowaną klasę, taką jak komponent, złącze i reprezentacja): http://www.restlet.org/

Jesteśmy pragmatycznymi programistami, a nasi użytkownicy rozwijają rzeczywiste aplikacje za pomocą naszego frameworka RESTful (dla Javy i GWT). Zwolennicy odpoczynku nie są pedantyczni, ale istnieje krzywa uczenia się, jak dla każdej ważnej technologii.

 3
Author: Jerome Louvel,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-08-10 19:28:03

/ Align = "center" bgcolor = "# e0ffe0 " / cesarz chin / / align = center /

/Książki.php?category = ruby 

GET /search?type=books&category=ruby

/Książki.php?id = 23 

GET /books/23 (or /books/23.xml)

/Książki.php?action=add&title = AdvancedRuby&description=....&securityId=923847203487 

POST /books
title=AdvancedRuby&description=A+great+book...

/Książki.php?action=delete&id=342&securityId=923847203487 

DELETE /books/342

Wielu programistów trzyma się GET I POST w takim przypadku ostatni może być: 

POST /books/342
status=Deleted
 2
Author: pbreitenbach,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-07-04 06:42:27

REST jest ciekawą i potencjalnie przydatną technologią, ale niestety wydaje się przyciągać najbardziej pedantyczną kolekcję programistów.

Wydaje się, że woleliby implementację podążającą za resztą dogmatu do litery, mimo że oznacza to całkowitą utratę funkcjonalności. Każde odstępstwo od czystego odpoczynku będzie traktowane jako herezja.

 1
Author: James Anderson,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-12-05 10:17:58

Nic nie znajduję w odpoczynku. Dla mnie jest to świetna koncepcja z abstrakcyjnego punktu widzenia dla maniaków internetowych, którzy nie mają do czynienia z bardziej surowymi kwestiami kodowania związanymi ze złożoną komunikacją HTTP.

Byłoby miło, gdyby dostępne było REST API, które wyodrębniało nas z całego HTTP. Ale tak nie jest. zamiast tego, REST proponants muszą wykonać pracę sprzedaży, aby napisać takie API z wszystkimi towarzyszącymi problemami debugowania i testowania.

The day I see a REST 1.0 header, poszukam jeszcze raz, aby znaleźć przewagę wartą wysiłku.

 -4
Author: Mike Trader,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-12-05 10:43:50