2012-01-25 11 views
8

Ogólnie mówiąc, społeczność REST wydaje się nie lubić złożonych danych w żądaniach GET. Zastanawiam się, czy kryje się za tym dobra zasada, czy też jest to tylko uzasadnienie restrykcji (arbitralna długość URL) dla słowników GET?REST i GET ... ponownie

Jestem zadowolony z korespondencji między adresami URL i zasobami, ale dlaczego moje żądania GET nie mogą zawierać złożonych danych w treści żądania, w json lub xml (co jest dozwolone w specyfikacji HTTP)?

Punkt GET, ponieważ zrozumiałem, że żądania GET sygnalizują, że nie modyfikują stanu serwera. Wydaje się to ortogonalne w stosunku do złożoności wniosku. Jednak wiele osób sugeruje tworzenie złożonych zapytań za pomocą PUT lub POST, a następnie odniesienie do GET.

Wydaje się to podnosić konwencję (braku ciał na żądanie GET) do statusu zasady, z niefortunnymi efektami ubocznymi: konieczności utrzymywania stanu innego obiektu, który nie zasługuje na bycie zasobem na własny - to jest zapytanie.

Być może jest jeszcze inna zasada, której mi brakuje - cieszę się z Waszych komentarzy!

Odpowiedz

4

Obawiam się, że istniejący pośrednicy WWW zrzucą ciało GET. Na szczęście nowe specyfikacje httpbis przeredagowały tekst na temat ciał get i sprawiły, że stał się trochę mniej przerażający. Osobiście zastanawiam się, czy używać samych ciał, ponieważ chcę rejestrować niebezpieczne żądania, aw tej chwili nie mam łatwego sposobu określenia, czy test POST jest bezpieczny, czy nie. Jeśli masz kontrolę nad komponentami, które znajdują się między twoim agentem użytkownika i serwerem pochodzenia, to mówię: śmiało, używaj GET-ów z ciałami.

+0

ciekawe ... czy ktoś może podzielić się swoimi niefortunnymi doświadczeniami ze zrzuconymi ciałami "na wolności"? – shaunc

+0

Nie, ale jaki masz plan, jeśli go spotkasz? –

+0

Włącz ogon i uciekaj! Ale jeśli jest to tylko przerażająca legenda i nigdy nikogo nie spotkało (słuchanie), to sprawia, że ​​jestem trochę bardziej pewny siebie. – shaunc