如何設計可擴展的靜態/非靜態API？

Question

我有一個API“ x”，它今天對4個參數-a，b，c，d進行了CRUD。 明天如果由於需求的變化，如果我必須在同一API中支持更多的參數，那么最好的處理方法是什么？

我是否應該繼續使用引入的新參數更新數據庫，並在需求發生變化時繼續執行此操作？

我的一位同伴建議API應該接受一個JSON對象，該對象可以接受任何一組參數和任何一組鍵值對。 每次通過此JSON獲得一組新的鍵值對時，都會使用該值更新我的params表，然后需求可以隨時隨地更改。

我認為這很難在客戶端之間維護，因為API實際上會接受任何鍵值對，因此一個平台可能會辯論以一種格式發送這些鍵值對，而另一種平台則願意以另一種格式發送。格式。 另外，將很難進行驗證並檢查可選和強制參數。

任何線索表示贊賞

Answer 1

我的回答有些細微差別，所以要當心。

我發現在實踐中，我們不會對API進行太多更改，而當我們這樣做時，我們通常可以采用向后兼容的方式來進行更改。 這確實意味着我們添加了可選字段。

如果您控制所有客戶端，這也相當容易，因為您可以升級所有客戶端，因此這並不是真正的問題。

當您進行更多更改或僅添加一些屬性而做的事情時，這將變得更加困難，並且這是與您聯系的第三方，您可以輕松地對其進行升級。

有多種解決方法，但是我的建議是遵循github的模型。

對於較大的重大更改，它們將更改Content-Type標頭。 當前，github請求的Content-Type為：

Accept: application/vnd.github.v3+json

在他們進行重大突破之前，它是：

Accept: application/vnd.github.v2+json

對於易於更改的實驗性API，可以使用實驗性Content-Type ：

Accept: application/vnd.github.mister-fantastic-preview+json

通常，此想法可用於寧靜的設計，但不是唯一的解決方案。