使用複雜SQL操作的REST API

我有一堆標準化表，名爲danger,countermeasure和module。現在我有一個三列表krt表示三個表之間的連接。（列名稱danger_id,countermeasure_id,module_id）正常端點如/danger顯示了相關表格的元素。使用複雜SQL操作的REST API

/krt?where={result: module, danger_id: x}將查詢表krt所有與danger_id == x的危險並將結果與模塊表結合在一起。結果會是什麼樣子（轉換顯示）

danger_id: 
- module a 
- module b 
danger_id2: 
- module .. 
[...]

我當然可以提供一個視圖，並添加自定義端點這一觀點。但是，不僅有三種可能的觀點，而且更復雜的觀點有一個或兩個額外的聯合。（如果需要，也可以提供示例）

因此，這種查詢和加入共同概念還是違反了此設計中的任何REST約束？有沒有更好/更直觀的方式來提供這樣的信息？

來源

2016-08-26 matt3o

仍然希望有一點經驗的人。我認爲它可能至少會破壞緩存性原則，因爲底層文檔是生成的而不是從數據庫中提取的。在每次請求中，連接都必須重新進行。 – matt3o

如果你問有關如何將REST風格的URL看起來，它可能是這樣的

/krt?dangerId=x&result=module

你如何決定構建一個SQL查詢是不相關的REST風格的設計，在我看來。

也沒有指導說每個GET請求都必須可緩存 - 也取決於其他因素。如果你的數據是相當靜態的，但經常需要足夠的時間，那麼你甚至可以在很短的時間內緩存它。

來源

2016-08-27 07:56:12

查詢類型也沒有真正指定 - 我只是使用JSON語法。根據[Wikipedia]（https://en.wikipedia.org/wiki/Representational_state_transfer#Architectural_constraints），有6個約束條件，而cachability就是其中之一。是的，我可以緩存它，但是我無法真正監控底層數據何時發生變化，因爲它只是數據太多，並且不能真正承受，尤其是當許多人同時使用它時。所以我不會稱之爲「緩存」。可能會這樣做，但這不會是一個REST API，因爲這個原因。 – matt3o

「因此，響應必須隱式或顯式地將自己定義爲可緩存，**或不**」 - 我會將其解釋爲能夠應用緩存 - 這在技術上將是！不要以爲一秒鐘內所有的RESTful API GET請求都會被緩存 - 這也是一個商業決策。 –

我明白你的意思 - 我可以緩存它。但不是在知道底層數據何時發生變化時，我會更新緩存，而不是用來保持狀態的愚蠢緩存。一個小時。好點子。除此之外 - 你認爲它或多或少符合REST原則嗎？ – matt3o

使用複雜SQL操作的REST API

回答

相關問題