從質量檢查角度進行其餘API和資源驗證

Question

從質量檢查角度進行其餘API和資源驗證

6

在當前項目中，讓"玩具"為類別，"槍"為產品。玩具類別的ID為2，槍支產品的ID為1。

類別的URI為/api/v1/categories/<category_id>。

產品的URI為/api/v1/product/<product_id>。

因此，我們在/api/v1/categories/2處擁有玩具類別，在/api/v1/product/1處擁有產品槍。

要刪除特定產品，我們必須對特定產品URI發出DELETE請求，例如DELETE /api/v1/product/1。

但是對於創建產品，我們必須轉到/api/v1/product/2並創建具有名稱和價格的產品，並且產品資源ID（給定URI中為2）實際上是類別ID。

因此，在此示例中，如果我使用.../product/2，則會在玩具類別下創建產品，因為玩具是ID為2的類別。

但是我提出了反對意見，建議創建一個類別下的玩具，然後POST操作應位於該類別下。在此示例中，要創建產品，我們必須轉到/api/v1/categories/2並創建具有名稱的產品，然後將在玩具類別中創建價格和產品。

但是開發人員堅持認為實現是正確的，並且它是REST API，因此用於創建產品的HATEOS將指向/api/v1/product/<category_id>，因此無需在類別資源本身下執行此操作。

作為質量檢查人員，我們對這種設計的反應是什麼？

應該忽略它，還是有質量保證遵循的良好實踐來確保REST端點的質量？

什麼是REST API驗證的好清單？

來源分享

創建於2020-03-25 15:46:312020-03-25 15:46:31 PDHide

1 答案

globalworming · Answer 1 · 2020-06-23T08:09:48Z

As QA you are correctly getting a weird feeling. REST aims to do CRUD on resources in a standardized way. By adhering to that standard, you decrease the mental load on the next developer trying to figure out how the application works. Making exceptions to the standard would increase technical debt.

So this issue needs to be addressed and if the one person says "it's fine", address it in the team. Research and present what the standard is for and when it is valid to deviate from the standard.

If the team as a whole is fine with making exceptions.. I guess you have to accept that and focus on other aspects of the API. If you see the problem getting worse, bring it up again at a later point.

從質量檢查角度進行其餘API和資源驗證

1 答案