線上產品瀏覽系統的 API 規劃

今天接著試試不同區域的工作流程範例。

更新

[ PUT ] api/products/{product} ：更新單一產品全部資料
[ PATCH ] api/products/{product} ：修改單一產品部分資料

兩個請求對應到的都是 ProductController 的 update 方法

我的理解

[ PUT ] 是完全更新產品的全部資料。

[ PATCH ] 是更新部份資料。

但以使用者體驗上，我覺得此專案的需求只需要用到：

[ PATCH ] api/products/{product} ：修改單一商品部分資料

更新邏輯

例如：想更新產品名稱
先驗證需要更改的名稱是否符合我自訂的規則，符合的話便更新，更新後便回傳更新後的完整資料。

ProductController.php 的 update 方法

    public function update(Request $request, Product $product)
    {
        // 驗證規則
        $rules = [
            'type_id' => 'sometimes|integer|min:0',
            'product_name' => 'sometimes|string|max:255',
            'product_description' => 'nullable',
            'price' => 'sometimes|integer|min:0',
        ];

        // 驗證請求資料
        $validatedData = $request->validate($rules);
        // 更新商品資料
        $product->update($validatedData);

        // 回傳更新後的資料
        return response()->json([
            'message' => '商品資料更新完成!',
            'product' => $product
        ], 200);
    }

sometimes 規則是什麼？

在 Laravel 中，sometimes 規則主要用於允許部分更新時的驗證。

意思是當你更新資料時，如果某個欄位在請求中沒有提供，這個欄位的驗證將被「忽略」。

而這對於需求是「只想更改其中一些屬性」這種情況非常有用。

例如：

如果請求只包含 product_name 和 price，而不包含 type_id 和 product_description，那麼 Laravel 將不會對這兩個欄位進行驗證，而是只會驗證和更新提供的欄位。

所以使用 sometimes 的好處是可以靈活處理請求，避免不必要的驗證錯誤，提升使用者體驗。

更多驗證規則的相關資訊可以參考 Laravel 的官方文件：

• Laravel Validating When Present
• Laravel Validation Documentation

使用 Postman 測試

將原本的價錢從 220 更改成 230

顯示更新完成的訊息及更新後的產品資料，即測試成功！