差異處
這裏顯示兩個版本的差異處。
Both sides previous revision 前次修改 下次修改 | 前次修改 | ||
java:web:restapi:http_method_cant_make_sense [2017/09/26 22:34] tony |
java:web:restapi:http_method_cant_make_sense [2023/06/25 09:48] (目前版本) |
||
---|---|---|---|
行 14: | 行 14: | ||
PATCH /Systems/1/BIOS/Settings | PATCH /Systems/1/BIOS/Settings | ||
</code> | </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> | <code> | ||
PUT /ManagedDevice/firmware | PUT /ManagedDevice/firmware | ||
行 128: | 行 128: | ||
這裡我並沒有使用DELETE,因為在語義上使用DELETE power_on不會比PUT power_off來得清楚。此外,在使用這種方式後,hypermedia可以很容易的使用URI去表達出不同的意義。剩下的問題就是synchronized。\\ | 這裡我並沒有使用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去操作: | 另外一個選擇,就是把它當controller resource,使用POST去操作: | ||
行 169: | 行 169: | ||
} | } | ||
</code> | </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? ==== | ==== Threat the P/N action as a store resource or use PATCH? ==== | ||
在我們的專案中,P/N action我傾向使用store resource大於PATCH。主要原因有以下: | 在我們的專案中,P/N action我傾向使用store resource大於PATCH。主要原因有以下: | ||
行 186: | 行 186: | ||
file.locked = Boolean.parseBoolean(updateFile.locked); | file.locked = Boolean.parseBoolean(updateFile.locked); | ||
if( updateFile.name != null ) | if( updateFile.name != null ) | ||
- | file.name = updateFile.name; | + | file.name = updateFile.name; |
return new ResponseEntity<String>("good", HttpStatus.OK); | return new ResponseEntity<String>("good", HttpStatus.OK); | ||
} | } |