如何正確地對接口進行防御式編程
我們平時做業務開發工作，本質上是處理數據與存儲、邏輯的關系。而我們程序的數據，絕大部分來自外部接口輸入，對接口輸入的檢查必須要做。否則就會導致應用和各個微服務的數據被寫臟，出現各種數據不一致的問題，進而引發運行時邏輯出錯和程序 crash 等問題。這時防御式編程的重要性就體現出來了，而大家也清楚這一點。
但是在具體的工作中，我發現很多同學沒有做對接口入參的校驗，完全信任外部系統的入參；有部分同學做了校驗，但是不全面。那到底該怎么正確、優雅、全面地對接口入參進行校驗，做好防御式編程呢？這就是我們接下來要討論的問題。
假設我們有這樣一個需求：設計一個訂單商城系統。它會涉及到商品創建、商品發布、用戶購物車管理、用戶下單、購買、取消訂單等非常多的用例。以商戶端創建商品這個接口設計為例，我們看下如何運用防御式編程來處理。
class CreateProductRequestData {
privateProductproduct;
}
classProduct {
privateStoreIdstoreId;
privateStringname;
privateStringimageId;
privateTypetype;
privateList<SKU> skus;
...
}針對前端提交的創建商品的數據，我們必須對數據做正確、全面的校驗，防止客戶端寫 Bug 或者黑客攻擊導致系統應用數據被寫臟。
在這個 case 中，我們要根據產品需求校驗參數，在和前端開發同學定義好接口文檔后，也同樣要按照定義去校驗參數。storeId 必傳、商品 name 必傳、type 必須為枚舉中的值、以及逐個校驗 skus 中的 sku。
if (storeId == null) {
throw new ApiException("storeId 不允許為 null");
}
if (Strings.isNullOrEmpty(name)) {
throw new ApiException("name 不允許為 null");
}
if (type == null) {
throw new ApiException("產品類型 type 不允許為 null");
}
if (CollectionUtils.isEmpty(skus)) {
throw new ApiException("skus 不允許為空");
}
// 校驗skus我們來看上面這段校驗代碼。其實在工作中，我們通常不會這么寫，而是抽出單獨的工具類，對前端接口或者微服務跨系統之間的調用參數進行斷言校驗。如果參數內容和接口定義不符或者和產品需求不一致，就拋出 Exception，由自定義的全局異常處理器捕獲 Exception。在我們的例子里是 ApiException，然后生成 response 返回前端。ApiException 代表客戶端寫出了 Bug，或者有黑客對接口進行攻擊，亂傳入參數引發的異常。
這段代碼片段是我們抽出的通用工具類，可以用來校驗前端參數和微服務跨系統調用的入參：
public class Asserts {
//校驗表達式，可以用來檢查客戶端接口數據的邏輯關聯性
publicstaticvoidassertTrue(String description, boolean value) {
if(!value) {
thrownewApiException(description);
}
}
//校驗字段不為空
publicstaticvoidassertFieldNotEmpty(String field, String value) {
assertFieldNotEmpty(field, value, false /* trim */);
}
// 校驗字段不為空的重載方法
publicstaticStringassertFieldNotEmpty(String field, String value, boolean trim) {
booleanfieldNotEmpty = value != null;
if(fieldNotEmpty) {
if(trim) {
value = value.trim();
}
if(Strings.isNullOrEmpty(value)) {
fieldNotEmpty = false;
}
}
if(!fieldNotEmpty) {
thrownewApiException("字段" + field + "不應為空。");
}
returnvalue;
}
//校驗字段不為null
publicstaticvoidassertFieldNotNull(String field, Object value) {
if(value == null) {
thrownewApiException(field + " 不應為 Null.");
}
}
//... 其他校驗方法
}這里需要提醒你一點，在防御式編程中，我們要盡可能地處理錯誤，而不是異常。這句話怎么理解呢？還是拿剛才的例子來說，假如不校驗 storeId，任由 null 值進入系統，那么在系統運行中，我們就必然要處理因為 storeId 為 null 而產生的 crash，例如 NullPointerException。現在我們在接口層校驗處理了這個錯誤（校驗 storeId 不為 null），那么就可以保證應用中的數據是安全的，是經過檢查的，沒有臟數據。其他字段的校驗也是一樣的作用，通過對外部數據進行校驗，做防御性保護，盡可能處理錯誤，我們的系統就會非常干凈，運行狀態也會非常健康。
你可能會問，那如果接口數量很多，該怎么設計，在什么地方校驗這些參數？針對這個問題，可以這么解決，我們定義一個 Validatable 通用接口，里面只有一個方法 validate()，它是一個通用校驗的鉤子方法。我們的各種 RequestData、各種 model(可以是 RequestVO) 實現這個接口，實現 validate 鉤子方法，做業務相關的參數檢查。
比如這段代碼片段，我們可以對之前的代碼做改造和重構，讓它們變得更加優雅。這樣每個 RequestData 只關心自己的校驗邏輯，做好自己的防御性保護就行了。
public interface Validatable {
void validate();
}
public class ProductimplementsValidatable {
privateStoreIdstoreId;
privateStringname;
privateStringimageId;
privateTypetype;
privateList<SKU> skus;
// product的其他屬性
@Override
publicvoidvalidate() {
Asserts.assertFieldNotNull("storeId", this.storeId);
Asserts.assertFieldNotEmpty("name", this.name);
Asserts.assertFieldNotNull("type", this.type);
Asserts.assertTrue("skus 不允許為空",!CollectionUtils.isEmpty(skus));
for(SKU sku : skus) {
sku.validate();
}
// ...校驗product的其他字段
}
}
publicclassSKUimplementsValidatable {
privateintordinal;
privateStringname;
// ...sku的其他屬性
@Override
publicvoidvalidate() {
Asserts.assertFieldNotEmpty("name", this.name);
// ...校驗sku的其他字段
}
}
publicclassCreateProductRequestDataimplementsValidatable{
privateProductproduct;
@Override
publicvoidvalidate() {
Asserts.assertFieldNotNull("product", this.product);
product.validate();
}
}這里有一個問題，這么多 RequestData，我們在開發中到底如何關聯具體的處理器呢？我在這里也分享一種解決方案。你可以定義與 RequestData 對應的 RequestHandler，然后通過泛型綁定 RequestData 和 ResponseData。通過一個特定的 handlerRepo 在容器啟動的時候就把這些 handler 全部組裝好。這樣，我們增加一個接口時只需要增加對應的 RequestData、ResponseData 和 handler，滿足了對擴展開放，對修改關閉。請求來的時候，根據請求路徑能知道具體的 handler，在這里可以回調 validate 鉤子完成校驗。你可以參考這段代碼：
@Service
public class CreateProductRequestHandlerextendsRequestHandler<CreateProductRequestData,CreateProductResponseData>{
@Override
publicCreateProductResponseDataexecuteRequest(RequestContext,
CreateProductRequestData req) {
// ...
}
}
@Service
publicclassHandlerRepo {
// 當web容器接收請求（請求url約定就是key）后，通過key拿到RequestEntry中的handler,根據requestClazz反序列化出對應的RequestData，再統一校驗，調用validate鉤子方法。validateRequestData可以做在RequestHandler抽象類中，讓具體開發接口的同學無需關心如何調用validate方法。此處設計不在本次課程中。
classRequestEntry {
finalRequestHandlerhandler;
finalClass<? extendsApiRequestData> requestClazz;
finalClass<? extendsApiResponseData> responseClazz;
// ...
}
privatefinalMap<String, RequestEntry> map = Maps.newHashMap();
@Autowired
publicvoidinitHandlers(RequestHandler<? extends ApiRequestData,
? extends ApiResponseData>[]) {
// 把每一個RequestHandler解析成RequestEntry,key可以是包名加類名的分割，如
/api/com/abc/xyx/createProduct
}
}在關于接口相關的防御式編程中，除了要校驗系統外部數據的格式和合法性之外，有的校驗還需要上下文的支持。
例如，在我們這一講的例子中，除了常規參數校驗，還需要校驗 storeId 的邏輯關系。這句話怎么理解？當商戶端在后臺登錄時，登錄態中可以拿到當前商家信息。接口提交上來的 storeId，必須是當前商家所屬的 Store，因為肯定不能創建其他商家的產品。這種校驗，其實很多同學都會忽略，但又是非常重要的。假如不校驗，有人繞過界面調用接口，傳入其他 storeId，就會引發服務器 Bug，造成應用數據被寫臟。這種錯誤校驗也屬于 ApiException，我們認為也是客戶端 Bug。
正確的校驗命令，你可以參考這段代碼：
public void createProduct(Product product) {
Asserts.assertTrue("只能創建自己的商品：" + product.getStoreId(), product.getStoreId() == RequestContext().getSession().getStoreId());
//... 產品信息入庫邏輯
}當然了，在實際的工作中，還有很多情況是需要結合上下文來校驗前端參數的。比如刪除文章這個接口，在產品設計上，我們只能刪除自己的文章，如果客戶端提交上來的文章作者是其他用戶，你沒有經過校驗就做刪除，那就是不對的。在我的職業經歷中，無論是大型互聯網公司，還是創業公司，很多業務代碼都沒有這種防御處理，完全信任客戶端的入參，這種做法非常危險。所以，服務器對于這種在異常交互下提交上來的參數，必須做檢查。我們考慮得越全面，寫出來的代碼就越健壯，應用數據越安全。
我用一張思維導圖給你總結一下講的內容。對于接口的防御式編程處理方式呢，我們首先要進行契約檢查，也就是數據格式、定義是不是合法的，這是最基本的校驗要素。其次，還要檢查接口入參有沒有邏輯上的 Bug，這需要結合你當前的具體業務來判斷，因為接口本質上只是一個輸入輸出，不應該和具體的界面聯系起來。
圖片
