Elasticsearch GET請求與請求正文

是不是違背REST風格的方法來傳遞請求正文與GET請求？Elasticsearch GET請求與請求正文

例如以過濾Elasticsearch

一些信息

curl localhost:9200/megacorp/employee/_search -d '{"query" : {"filtered" : {"filter" : {"range" : {"age" : { "gt" : 30 }}},"query" : {"match" : {"last_name" : "smith"}}}}}'

一些工具甚至設計，以避免請求主體的GET請求（如郵遞員）

來源

2016-04-29 yurko

看到這個答案可能有所幫助：http://stackoverflow.com/questions/34795053/es-keeps-returning-every-document/34796014#34796014 – Val

有關GET和Body的詳細解答 - https://stackoverflow.com/a/8502004/1589840 – serhiisavruk

不行，這不行。

在REST中，使用POST進行查詢沒有任何意義。 POST應該修改服務器。在搜索時顯然不要修改服務器。

GET很適用於此。

這就是說，我們知道一些語言和工具不允許這樣做。雖然RFC沒有提到你不能有一個身體GET。

所以elasticsearch也支持POST。

此：

curl -XPOST localhost:9200/megacorp/employee/_search -d '{"query" : {"filtered" : {"filter" : {"range" : {"age" : { "gt" : 30 }}},"query" : {"match" : {"last_name" : "smith"}}}}}'

會的工作方式相同。

來源

2016-04-29 13:52:55 dadoonet

如果您聲稱發送帶有body的get請求是RESTful，那麼您如何解釋[this]（https://stackoverflow.com/a/983458/1057791）？ – BornToCode

-1這就是爲什麼它與所有這些解釋混亂。如果語義會被忽略，爲什麼會需要這麼多的請求類型。 RESTful API不應考慮GET終端中的主體。有彈性的堆棧只是一個黑客，並不成熟，需要做很多工作（像大多數新的開源項目，沒有什麼不對，有時間做得更好）。如果GET中沒有主體，則不需要POST端點替代方案......這就是爲什麼它是混亂的，沒有約定。我實際上是在URL中留下路徑來決定，但REST被設計爲使用HTTP semanti –

一個HTTP請求類型來統治它們，這是我認爲最好的方式和最靈活的方式，併爲那些實施和使用該協議，通過網址。這樣就不會有一些端點模糊（他們到底在做什麼）。我不是REST的粉絲。我對簡單性和靈活性以及一見鍾情易懂的東西很感興趣 –

Elasticsearch GET請求與請求正文

回答

相關問題