Jakie są najlepsze / najczęściej używane czasowniki i czynności związane z adresami URL RESTful?

Question 1

Próbuję znaleźć informacje na temat najlepszych i najczęstszych działań adresów URL RESTful.

na przykład jakiego adresu URL używasz do wyświetlania szczegółów przedmiotu, do edycji przedmiotu, aktualizacji itp.

/question/show/<whatever>
/question/edit/<whatever>
/question/update/<whatever> (this is the post back url)
/question/list   (lists the questions)

hmm. dzięki wszystkim, którzy pomagają :)

Question 2

Użyj adresów URL, aby określić obiekty, a nie działania:

Zwróć uwagę, że to, o czym wspomniałeś, nie jest RESTful:

/questions/show/<whatever>

Zamiast tego do określenia obiektów należy użyć adresów URL:

/questions/<question>

Następnie wykonujesz jedną z poniższych operacji na tym zasobie.

OTRZYMAĆ:

Służy do uzyskiwania zasobu, wykonywania zapytań o listę zasobów, a także do wysyłania zapytań o informacje tylko do odczytu dotyczące zasobu.

Aby uzyskać zasób pytań:

GET /questions/<question> HTTP/1.1
Host: whateverblahblah.com

Aby wyświetlić wszystkie zasoby związane z pytaniami:

GET /questions HTTP/1.1
Host: whateverblahblah.com

POCZTA:

Służy do tworzenia zasobu.

Zwróć uwagę, że następujący błąd to:

POST /questions/<new_question> HTTP/1.1
Host: whateverblahblah.com

Jeśli adres URL nie został jeszcze utworzony, nie należy używać POST do jego tworzenia podczas określania nazwy. Powinno to spowodować błąd „Nie znaleziono zasobu”, ponieważ jeszcze nie istnieje. Najpierw należy umieścić zasób na serwerze. Możesz argumentować, że tworząc nowe pytanie, aktualizujesz również zasób / questions, ponieważ teraz zwróci ono jeszcze jedno pytanie na swojej liście pytań.

Powinieneś zrobić coś takiego, aby utworzyć zasób za pomocą POST:

POST /questions HTTP/1.1
Host: whateverblahblah.com

Zauważ, że w tym przypadku nazwa zasobu nie jest określona, ścieżka URL nowego obiektu zostanie zwrócona.

USUNĄĆ:

Służy do usuwania zasobu.

DELETE /questions/<question> HTTP/1.1
Host: whateverblahblah.com

POŁOŻYĆ:

Służy do tworzenia zasobu lub nadpisywania go podczas określania adresu URL zasobów.

W przypadku nowego zasobu:

PUT /questions/<new_question> HTTP/1.1
Host: whateverblahblah.com

Aby nadpisać istniejący zasób:

PUT /questions/<existing_question> HTTP/1.1
Host: whateverblahblah.com

... Tak, są takie same. PUT jest często opisywany jako metoda „edycji”, ponieważ zastępując cały zasób nieznacznie zmienioną wersją, edytowałeś to, co klienci otrzymają, gdy zrobią to później.

Korzystanie z REST w formularzach HTML:

Specyfikacja HTML5 definiuje GET i POST dla elementu formularza .

Atrybut zawartości metody jest wyliczonym atrybutem z następującymi słowami kluczowymi i stanami:

Słowo kluczowe GET, mapujące na stan GET, wskazujące metodę HTTP GET.

Słowo kluczowe POST, mapujące do stanu POST, wskazujące metodę HTTP POST.

Technicznie specyfikacja HTTP nie ogranicza Cię tylko do tych metod. Z technicznego punktu widzenia możesz dodawać dowolne metody, jednak w praktyce nie jest to dobry pomysł. Chodzi o to, że wszyscy wiedzą, że używasz GET do odczytywania danych, więc będzie to skomplikowane, jeśli zdecydujesz się zamiast tego użyć READ. To mówi...

ŁATA:

Jest to metoda zdefiniowana w formalnym dokumencie RFC. Jest przeznaczony do użycia, gdy chcesz wysłać tylko częściową modyfikację zasobu, będzie używany podobnie jak PUT:

PATCH /questions/<new_question> HTTP/1.1
Host: whateverblahblah.com

Różnica polega na tym, że PUT musi wysłać cały zasób, bez względu na to, jak duży jest on w porównaniu z tym, co faktycznie się zmieniło, podczas gdy PATCH możesz wysłać tylko zmiany.

Question 3

Zakładając, że /questions/10jest to ważne pytanie, metoda jest używana do interakcji z nim.

POST, aby dodać do niego

PUT, aby go utworzyć lub zamienić

POBIERZ, aby wyświetlić / zapytać

i DELETE, aby dobrze ... usunąć to.

Adres URL się nie zmienia.

Question 4

Zamierzam wyjść na prostą i zgadnę, że masz na myśli standardowe kontrolery MVC, kiedy mówisz adresy URL „RESTful”, ponieważ twoje przykłady można uznać za inne niż „RESTful” (zobacz ten artykuł).

Ponieważ Railsy naprawdę spopularyzowały styl URL, którym wydajesz się być zainteresowany, poniżej przedstawiam domyślne akcje kontrolera utworzone przez ScaffoldingGenerator w Ruby on Rails. Powinien być znany każdemu, kto używa aplikacji Railsowej.

Działania i widoki szkieletowe to: indeksowanie, lista, pokazywanie, nowe, tworzenie, edycja, aktualizowanie, niszczenie

Zwykle można to skonstruować jako:

http://application.com/controller/<action>/<id>

Question 5

Oto mapowanie twoich obecnych adresów URL przy użyciu zasady REST:

/question/show/<whatever>

Jeśli określisz pytanie jako zasób, powinno mieć unikalny adres URL. Używanie GET do wyświetlania (pobierania) jest powszechną praktyką. Staje się:

GET /question/<whatever>

/question/edit/<whatever>

Teraz chcesz, aby użytkownik miał inny widok tego samego zasobu, który umożliwia mu edycję zasobu (być może za pomocą kontrolek formularza).

Dwie opcje tutaj, twoja aplikacja jest aplikacją (nie witryną internetową), wtedy możesz lepiej użyć JavaScript do przekształcenia zasobu w edytowalny zasób po stronie klienta.

Jeśli jest to witryna internetowa, możesz użyć tego samego adresu URL z dodatkowymi informacjami, aby określić inny widok, powszechną praktyką jest:

GET /question/<whatever>;edit

/question/update/<whatever> (this is the post back url)

Ma to na celu zmianę pytania, więc PUT jest właściwą metodą do użycia:

PUT /question/<whatever>

/question/list   (lists the questions)

Lista pytań jest w rzeczywistości nadrzędnym zasobem pytania, więc naturalnie jest to:

GET /question

Teraz możesz potrzebować więcej:

POST /question (create a new question and returns its URL)
DELETE /question/<whatever> (deletes a question if this is relevant)

Tada :)

Question 6

Twoje cztery przykłady to:

GET /questions/123
POST (or PUT) /questions/123 q=What+is+the+meaning+of+life
POST (or PUT) /questions/123 q=What+is+the+meaning+of+life
GET /questions

Aby dodać pytanie:

POST /questions q=What+is+the+meaning+of+life

Serwer odpowiedziałby:

200 OK (or 201 Created)
Location: /questions/456

Answer 1

Próbuję znaleźć informacje na temat najlepszych i najczęstszych działań adresów URL RESTful.

na przykład jakiego adresu URL używasz do wyświetlania szczegółów przedmiotu, do edycji przedmiotu, aktualizacji itp.

/question/show/<whatever>
/question/edit/<whatever>
/question/update/<whatever> (this is the post back url)
/question/list   (lists the questions)

hmm. dzięki wszystkim, którzy pomagają :)

Answer 2

Użyj adresów URL, aby określić obiekty, a nie działania:

Zwróć uwagę, że to, o czym wspomniałeś, nie jest RESTful:

/questions/show/<whatever>

Zamiast tego do określenia obiektów należy użyć adresów URL:

/questions/<question>

Następnie wykonujesz jedną z poniższych operacji na tym zasobie.

OTRZYMAĆ:

Służy do uzyskiwania zasobu, wykonywania zapytań o listę zasobów, a także do wysyłania zapytań o informacje tylko do odczytu dotyczące zasobu.

Aby uzyskać zasób pytań:

GET /questions/<question> HTTP/1.1
Host: whateverblahblah.com

Aby wyświetlić wszystkie zasoby związane z pytaniami:

GET /questions HTTP/1.1
Host: whateverblahblah.com

POCZTA:

Służy do tworzenia zasobu.

Zwróć uwagę, że następujący błąd to:

POST /questions/<new_question> HTTP/1.1
Host: whateverblahblah.com

Jeśli adres URL nie został jeszcze utworzony, nie należy używać POST do jego tworzenia podczas określania nazwy. Powinno to spowodować błąd „Nie znaleziono zasobu”, ponieważ jeszcze nie istnieje. Najpierw należy umieścić zasób na serwerze. Możesz argumentować, że tworząc nowe pytanie, aktualizujesz również zasób / questions, ponieważ teraz zwróci ono jeszcze jedno pytanie na swojej liście pytań.

Powinieneś zrobić coś takiego, aby utworzyć zasób za pomocą POST:

POST /questions HTTP/1.1
Host: whateverblahblah.com

Zauważ, że w tym przypadku nazwa zasobu nie jest określona, ścieżka URL nowego obiektu zostanie zwrócona.

USUNĄĆ:

Służy do usuwania zasobu.

DELETE /questions/<question> HTTP/1.1
Host: whateverblahblah.com

POŁOŻYĆ:

Służy do tworzenia zasobu lub nadpisywania go podczas określania adresu URL zasobów.

W przypadku nowego zasobu:

PUT /questions/<new_question> HTTP/1.1
Host: whateverblahblah.com

Aby nadpisać istniejący zasób:

PUT /questions/<existing_question> HTTP/1.1
Host: whateverblahblah.com

... Tak, są takie same. PUT jest często opisywany jako metoda „edycji”, ponieważ zastępując cały zasób nieznacznie zmienioną wersją, edytowałeś to, co klienci otrzymają, gdy zrobią to później.

Korzystanie z REST w formularzach HTML:

Specyfikacja HTML5 definiuje GET i POST dla elementu formularza .

Atrybut zawartości metody jest wyliczonym atrybutem z następującymi słowami kluczowymi i stanami:

Słowo kluczowe GET, mapujące na stan GET, wskazujące metodę HTTP GET.

Słowo kluczowe POST, mapujące do stanu POST, wskazujące metodę HTTP POST.

Technicznie specyfikacja HTTP nie ogranicza Cię tylko do tych metod. Z technicznego punktu widzenia możesz dodawać dowolne metody, jednak w praktyce nie jest to dobry pomysł. Chodzi o to, że wszyscy wiedzą, że używasz GET do odczytywania danych, więc będzie to skomplikowane, jeśli zdecydujesz się zamiast tego użyć READ. To mówi...

ŁATA:

Jest to metoda zdefiniowana w formalnym dokumencie RFC. Jest przeznaczony do użycia, gdy chcesz wysłać tylko częściową modyfikację zasobu, będzie używany podobnie jak PUT:

PATCH /questions/<new_question> HTTP/1.1
Host: whateverblahblah.com

Różnica polega na tym, że PUT musi wysłać cały zasób, bez względu na to, jak duży jest on w porównaniu z tym, co faktycznie się zmieniło, podczas gdy PATCH możesz wysłać tylko zmiany.

Answer 3

Cześć Brian… im więcej to czytam, tym bardziej sensownie. Zakładam, że niektóre przeglądarki (lub wersje przeglądarek) nie obsługują funkcji PUT lub DELETE? jeśli tak jest, czy zamiast tego używamy POST?

Pure.Krome

Answer 4

1

Cześć Pure.Knome; Przeglądarki internetowe obsługują je wszystkie, również każda biblioteka HTTP powinna je wszystkie obsługiwać.

Brian R. Bondy

Answer 5

4

Przy okazji polecam zakup tej książki, jeśli chcesz dowiedzieć się wszystkiego o REST oreilly.com/catalog/9780596529260

Brian R. Bondy

Answer 6

1

@Brian: jeszcze kilka pytań na temat przykładów z PUT. >> PUT / questions / <new_question> Dlaczego miałbyś to zrobić, zamiast robić >> PUT / questions / ponieważ wszystkie dane w formularzu zostaną użyte do stworzenia nowego zasobu? (ciąg dalszy następny komentarz) ...

Pure.Krome

Answer 7

1

@Brian R. Bondy, Dziękuję za wspaniałą odpowiedź. Żądanie POST do istniejącego zasobu jest opisane jako „dołączanie” w spokojnej książce Oreilly (str: 100,101), w przeciwieństwie do twojego ogólnego terminu „modyfikującego”. W końcu dołączanie jest bardziej szczegółowe niż modyfikowanie - co może przenosić „PUT do istniejącego zasobu” - i semantycznie brzmi bardziej poprawnie w przypadku POST - dodawanie nowego zasobu do określonego łącza, albo przez dołączenie do niego, albo utworzenie zasobu podrzędnego .

Özgür

Answer 8

11

Zakładając, że /questions/10jest to ważne pytanie, metoda jest używana do interakcji z nim.

POST, aby dodać do niego

PUT, aby go utworzyć lub zamienić

POBIERZ, aby wyświetlić / zapytać

i DELETE, aby dobrze ... usunąć to.

Adres URL się nie zmienia.

Allain Lalonde
źródło

4

Źle. PUT musi być idempotentny. Musisz mieć możliwość wielokrotnego wysyłania tego samego żądania PUT, bez żadnego efektu po pierwszym razem. Zatem tworzenie zasobu z każdym żądaniem PUT nie jest idempotentne.

aehlke

3

„Metody PUT i DELETE są zdefiniowane jako idempotentne, co oznacza, że wiele identycznych żądań powinno mieć taki sam efekt, jak pojedyncze żądanie.”, Użycie funkcji wstawienia identyfikatora URI, który obecnie nie udostępnia zasobu, może utworzyć zasób. Natychmiastowe PUT ponownie po prostu zrobiłoby to ponownie, co nie miałoby żadnego efektu. W ten sposób tworzysz zasób, ale zapytanie jest nadal idempotentne. Jeśli później wrócisz i zechcesz zmienić zasób, ustawisz PUT na ten sam identyfikator URI z różnymi danymi (co byłoby innym żądaniem i mogłoby zostać powtórzone dowolną liczbę razy z tym samym wynikiem).

Allain Lalonde

1

Właściwie spójrz na odpowiedź, która otrzymała 25 głosów powyżej, w której stwierdzono, że PUT może być używany do tworzenia lub zastępowania zasobu.

Allain Lalonde

3

Tworzenie działa tylko wtedy, gdy dozwolone jest określenie identyfikatora nowego zasobu. Chociaż jest to możliwe, częściej dla użytkownika wygodniej jest POST do / kolekcji i zwrócenie linków zawierających nowy identyfikator:

pgraham

2

@aehIke Utworzenie nowego zasobu przez PUT nie czyni go nie idempotentnym, ponieważ idea jest taka, że jeśli „PUT / items / 10” i element 10 nie istniał wcześniej, to zostanie po prostu utworzony. Jeśli jednak ponownie `` PUT / items / 10 '' po raz drugi, cóż, teraz już istnieje, więc zostanie po prostu zastąpiony, dlatego idempotencja zostaje zachowana, ponieważ kolejne żądania PUT nie mają nowego efektu ubocznego. (Oczywiście zakładając, że za każdym razem umieszczam ten sam dokładny przedmiot)

Alappin

Answer 9

4

Źle. PUT musi być idempotentny. Musisz mieć możliwość wielokrotnego wysyłania tego samego żądania PUT, bez żadnego efektu po pierwszym razem. Zatem tworzenie zasobu z każdym żądaniem PUT nie jest idempotentne.

aehlke

Answer 10

3

„Metody PUT i DELETE są zdefiniowane jako idempotentne, co oznacza, że wiele identycznych żądań powinno mieć taki sam efekt, jak pojedyncze żądanie.”, Użycie funkcji wstawienia identyfikatora URI, który obecnie nie udostępnia zasobu, może utworzyć zasób. Natychmiastowe PUT ponownie po prostu zrobiłoby to ponownie, co nie miałoby żadnego efektu. W ten sposób tworzysz zasób, ale zapytanie jest nadal idempotentne. Jeśli później wrócisz i zechcesz zmienić zasób, ustawisz PUT na ten sam identyfikator URI z różnymi danymi (co byłoby innym żądaniem i mogłoby zostać powtórzone dowolną liczbę razy z tym samym wynikiem).

Allain Lalonde

Answer 11

1

Właściwie spójrz na odpowiedź, która otrzymała 25 głosów powyżej, w której stwierdzono, że PUT może być używany do tworzenia lub zastępowania zasobu.

Allain Lalonde

Answer 12

3

Tworzenie działa tylko wtedy, gdy dozwolone jest określenie identyfikatora nowego zasobu. Chociaż jest to możliwe, częściej dla użytkownika wygodniej jest POST do / kolekcji i zwrócenie linków zawierających nowy identyfikator:

pgraham

Answer 13

2

@aehIke Utworzenie nowego zasobu przez PUT nie czyni go nie idempotentnym, ponieważ idea jest taka, że jeśli „PUT / items / 10” i element 10 nie istniał wcześniej, to zostanie po prostu utworzony. Jeśli jednak ponownie `` PUT / items / 10 '' po raz drugi, cóż, teraz już istnieje, więc zostanie po prostu zastąpiony, dlatego idempotencja zostaje zachowana, ponieważ kolejne żądania PUT nie mają nowego efektu ubocznego. (Oczywiście zakładając, że za każdym razem umieszczam ten sam dokładny przedmiot)

Alappin

Answer 14

Zamierzam wyjść na prostą i zgadnę, że masz na myśli standardowe kontrolery MVC, kiedy mówisz adresy URL „RESTful”, ponieważ twoje przykłady można uznać za inne niż „RESTful” (zobacz ten artykuł).

Ponieważ Railsy naprawdę spopularyzowały styl URL, którym wydajesz się być zainteresowany, poniżej przedstawiam domyślne akcje kontrolera utworzone przez ScaffoldingGenerator w Ruby on Rails. Powinien być znany każdemu, kto używa aplikacji Railsowej.

Działania i widoki szkieletowe to: indeksowanie, lista, pokazywanie, nowe, tworzenie, edycja, aktualizowanie, niszczenie

Zwykle można to skonstruować jako:

http://application.com/controller/<action>/<id>

Answer 15

5

Konwencje pozapasmowego identyfikatora URI NIE są RESTful. Cytując samego Fieldinga: „REST API 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 należy pozwolić serwerom instruować klientów, jak konstruować odpowiednie identyfikatory URI , na przykład w formularzach HTML i szablonach URI, definiując te instrukcje w typach mediów i relacjach linków. ”

aehlke

Answer 16

Oto mapowanie twoich obecnych adresów URL przy użyciu zasady REST:

/question/show/<whatever>

Jeśli określisz pytanie jako zasób, powinno mieć unikalny adres URL. Używanie GET do wyświetlania (pobierania) jest powszechną praktyką. Staje się:

GET /question/<whatever>

/question/edit/<whatever>

Teraz chcesz, aby użytkownik miał inny widok tego samego zasobu, który umożliwia mu edycję zasobu (być może za pomocą kontrolek formularza).

Dwie opcje tutaj, twoja aplikacja jest aplikacją (nie witryną internetową), wtedy możesz lepiej użyć JavaScript do przekształcenia zasobu w edytowalny zasób po stronie klienta.

Jeśli jest to witryna internetowa, możesz użyć tego samego adresu URL z dodatkowymi informacjami, aby określić inny widok, powszechną praktyką jest:

GET /question/<whatever>;edit

/question/update/<whatever> (this is the post back url)

Ma to na celu zmianę pytania, więc PUT jest właściwą metodą do użycia:

PUT /question/<whatever>

/question/list   (lists the questions)

Lista pytań jest w rzeczywistości nadrzędnym zasobem pytania, więc naturalnie jest to:

GET /question

Teraz możesz potrzebować więcej:

POST /question (create a new question and returns its URL)
DELETE /question/<whatever> (deletes a question if this is relevant)

Tada :)

Answer 17

Twoje cztery przykłady to:

GET /questions/123
POST (or PUT) /questions/123 q=What+is+the+meaning+of+life
POST (or PUT) /questions/123 q=What+is+the+meaning+of+life
GET /questions

Aby dodać pytanie:

POST /questions q=What+is+the+meaning+of+life

Serwer odpowiedziałby:

200 OK (or 201 Created)
Location: /questions/456

Jakie są najlepsze / najczęściej używane czasowniki i czynności związane z adresami URL RESTful?

Odpowiedzi: