Jest sobie serwis który dostaje coś na wejściu, obrabia i zwraca wynik, nie robiąc przy tym nic wiecej (bez side-effectów).
Przykład: dostaje słowo i zwraca je od tyłu.
Serwis ten powinien być obsługiwany przez GET czy POST i dlaczego?
0
0
Jeśli nie ma żadnych efektów ubocznych, najlepszym wyjściem jest GET - z prostego powodu: odpowiedzi na zapytania GET można bez problemu keszować (zarówno po stronie klienta, jak i serwera - np. za pomocą Varnisha), czego nie można powiedzieć o POSTach :-)
0
Dodatkowe wymaganie, zapytania dane mają przesyłane w body
4
danek napisał(a):
Dodatkowe wymaganie, zapytania dane mają przesyłane w body
Wtedy nie możesz użyć GET, bo if the request method does not include defined semantics for an entity-body, then the message-body SHOULD be ignored when handling the request.
0
danek napisał(a):
Dodatkowe wymaganie, zapytania dane mają przesyłane w body
Tak z ciekawości, skąd takie wymaganie ?
0
@error91: wielkość danych
0
Jeśli tych danych jest faktycznie sporo, to może warto jednak najpierw je wrzucić na serwer POSTem, a dopiero potem odpytywać GETem o obrobione dane?
- Nie będzie konieczności wielokrotnego przesyłania większych porcji danych do serwera jeśli będziesz powtarzał request
- nie złamiesz konwencji "GET bez body"
1
@superdurszlak: a jaki jest tego sens jeśli operacja trwa relatywnie krótko (to obrabianie danych)? Bo w tym przypadku widzę overkill
3
@superdurszlak: Ty chcesz jakąś sesję na serwerze trzymać?
@danek: jeśli body jest konieczne, to musi to być POST i nie ma w ogóle nad czym się zastanawiać. Nigdzie nie jest powiedziane, że POST nie może być używany do pobierania danych.
1
Generalnie to i tak mam trochę wrażenie ze metody http nie zostały zaprojektowane do tego typu operacja (a bardziej, nie po to powstały) i dlatego teraz powstają takie problemy