我想要在本篇部落格中介紹一下我在http api制定上的一些實踐，重點介紹api的返回格式，及實現及前端的處理流程。
網上的資料很多，不用多作介紹。
優點：充分利用了http的特性，正宗，規範。
缺點：1. 實現起來很麻煩，我在spring的官方示例中看過以下**
//模擬**，別當真controller層中對每乙個返回都會附上乙個狀態碼，這個顯得很多餘，且需要程式設計師熟知所有狀態碼。
2.語義上的混肴
我聽一同事說，曾和前端發生爭執，因為前端看到404以為是找不到頁面，其實是找不到資源。
儘管到目前為止，還沒有見過在專案中使用標準的restful協議，但它確實是乙個不錯的選擇，我想隨著spring-webflux的的普及，會有越來越多的人選擇使用restful協議。
class
result
缺點：沒有利用http狀態碼。所有的錯誤判斷要依據方法體中的資料
即使獲取乙個簡單型別的資料，介面呼叫端也要呼叫getresult來獲取具體內容。
呼叫重複**太多，雖然可以對上面的返回型別進行封裝，但我很少見過，很多呼叫端還是會有一堆if判斷。
不利於閘道器對其進一步改進。（以後會說明）
實現方案
1. 新增http狀態碼：460作為業務異常標識
2. 定義錯誤返回型別
3. 正確時，直接返回業務資料，或什麼都不返回，發生異常時，返回自義意的錯誤型別。
**展示
@controlleradvice
public
class
tm***ceptionhandler
@exceptionhandler()
responseentity notvalidexception
(methodargumentnotvalidexception ex)
}
不管是前端，還是android端，只需要在自己的http新增***，對460錯誤進行單獨攔截。（以後展示**）
缺點分析
雖然http協義規定：
4** 狀態碼表示：客戶端錯誤，請求包含語法錯誤或無法完成請求
但460卻是我的自定義狀態碼。並不是非常嚴格地符合http規範，如果用400可能更好，但可能引起混淆。
（未完……）
系統介面框架設計與實現
目錄 1 引言 2 設計 2.1 inte ce 2.2 business service 2.3 object transaction data 3 實現 3.1 webservice.asmx 3.2 ibusinessservice 3.3 common submitresult 4 使用說明...
設計類並實現介面與繼承
看到作業的時候想了一下，也不想搞太複雜的東西，所以在huang這個包裡就建立乙個父類，定義了乙個介面，然後在同乙個檔案裡繼承父類並實現介面 說明我真的太懶了 父類 evildoer是恐怖者的意思，scold是辱罵的意思 package com.huang class evildoer 定義的介面 p...
介面與 Dto 設計
以下為個人觀點，給出了基本增刪改查介面的設計，如有不同觀點，可以指正 dto設計 為每個實體建立乙個對應的dto 列表查詢 返回聚合根的dto列表或自定義的dto 單個實體查詢 返回整個聚合的dto或自定義的dto 以下是基本的命令介面 增刪改 根據業務邏輯是否允許如下操作進行新增 增加 增加乙個聚...