差異處

這裏顯示兩個版本的差異處。

--- java:web:restapi:http_method_cant_make_sense [2017/09/26 22:32]
tony [Case Study: Power Management]
+++ java:web:restapi:http_method_cant_make_sense [2023/06/25 09:48] (目前版本)
@@ 行 14: / 行 14: @@
 PATCH /Systems/1/BIOS/Settings
 </code>
-接著是更新firmware，以[[http://www.dell.com/support/manuals/tw/en/twdhs1/dell-active-system-mngr-v8.1/asm%20rest%20api-v1/manageddevicefirmware-put?guid=guid-ad63b2c1-00c4-4ce3-ad7a-a498e15f6636&lang=en-us|Dell ASM REST API]]為例，使用store resource的方式去操作:
+接著是更新firmware，以[[https://cpsdocs.dellemc.com/bundle/PFMGR_API_3/page/GUID-87FE88BA-FE97-4ECA-BF1E-46A23CC6414F.html|Dell ASM REST API]]為例，使用store resource的方式去操作:
 <code>
 PUT /ManagedDevice/firmware
@@ 行 128: / 行 128: @@
 這裡我並沒有使用DELETE，因為在語義上使用DELETE power_on不會比PUT power_off來得清楚。此外，在使用這種方式後，hypermedia可以很容易的使用URI去表達出不同的意義。剩下的問題就是synchronized。\\
 \\
-PUT回傳202的方式，我自己本身還沒看過範例，但HTTP規格書也沒說這樣是不對的。我覺得值得討論的部分是: idempotent。假設PUT回傳202，這代表著server將產生一個asynchronized的task，每次PUT power_on所產生的task是否會相同呢? 假如不同，是不是代表違反了idempotent? 假如相同，實作會不會蠻奇怪的呢? 這個我目前沒有答案。\\
+PUT回傳202的方式，目前有看過[[https://techlibrary.hpe.com/docs/enterprise/servers/oneview5.0/cicf-api/en/index.html#rest/enclosures|HPE OneView REST API]]存在這樣的設計；HTTP規格書也沒說這樣是不對的。我覺得值得討論的部分是: idempotent。假設PUT回傳202，這代表著server將產生一個asynchronized的task，每次PUT power_on所產生的task是否會相同呢? 假如不同，是不是代表違反了idempotent? 假如相同，實作會不會蠻奇怪的呢? 這個我目前沒有答案。\\
 \\
 另外一個選擇，就是把它當controller resource，使用POST去操作:
@@ 行 138: / 行 138: @@
 ===== Some questions =====
-針對以上提到的方法，我思考著幾個問題:
+針對以上提到的方法，我還思考著幾個問題:
 ==== Why don't you use the query string or formdata to pass the action? ====
 (這裡先撇開query string、formdata或request body等方式的差異) 對我而言，我目前認為有幾點需要考量:
   - hypermedia: 假如要表達出query string等方式，會需要使用template的方式，實作上不會比單純透過URI Path的方式容易。
   - http method convention: 如果在collection上使用POST，是否會讓新增與其它action讓使用者混淆。
-  - implementation:
+  - implementation: 我們看看如果使用URI的Path來實做lock與unlock可能會長怎樣:
-我們看看如果使用URI的Path來實做lock與unlock可能會長怎樣:
 <code java>
 	@RequestMapping(value = "/files/{fid}/lock", method = RequestMethod.PUT, produces = {"application/json"})
@@ 行 170: / 行 169: @@
 	}
 </code>
-你喜歡哪個? 假如File的action只有lock與unlock，那真的是天下太平；但事實上，action還有move、copy、rename等。考慮一下測試、維護、擴充的話，哪一個會比較好? 以擴充與維護來說，RequestParam的方式讓所有的action都必須接受同一組參數甚至輸出，增加了修改的麻煩；而URI Path則由各別的實做去決定。測試則是因為實做已分開，根據個別操作的目的去測試即可。
+你喜歡哪個? 假如File的action只有lock與unlock，那真的是天下太平；但事實上，action還有move、copy、rename等。考慮一下測試、維護、擴充的話，哪一個會比較好? 以擴充與維護來說，RequestParam的方式讓所有的action都必須接受同一組參數甚至輸出，增加了修改的麻煩；URI Path則由各別的實做去決定。測試則是因為實做已分開，根據各別操作的目的去測試即可。
 ==== Threat the P/N action as a store resource or use PATCH? ====
 在我們的專案中，P/N action我傾向使用store resource大於PATCH。主要原因有以下:
@@ 行 187: / 行 186: @@
 		file.locked = Boolean.parseBoolean(updateFile.locked);
 	if( updateFile.name != null )
-	file.name = updateFile.name;
+		file.name = updateFile.name;
 	return new ResponseEntity<String>("good",  HttpStatus.OK);
 }