道歉提前,Web服務的單一API或非方面多個API - 功能要求
的問題是微不足道的,但我對這個問題與我的客戶論點和我想知道正確的做法。
我正在開發一些銀行Web API以供移動應用程序以REST方式使用;諸如獲取用戶的銀行賬戶列表,賬戶餘額和轉賬金額等服務。
對於非功能性需求(如性能,安全性,維護和其他度量標準),以下模式之間是否存在差異?
模式1:
有一個請求和響應結構
public class Request
{
public string Command { get; set; } // Request Identifier
public string Args { get; set; } // Request Argumnets
}
public class Respond
{
public string Command { get; set; } // Respond Identifier
public string Results { get; set; } // Respond Result(s)
}
而且一個單一的API作爲
public Respond Process(Request request)
{
// process request and produces respond
switch(request.Command)
{
case 「GetBalance」:
return GetBalance(request.Args);
case 「TransferMoney」:
return TransferMoney(request.Args);
…
}
}
模式2:
哈詠多個API(S),一個API,每個服務
public BalanceResults GetBalance(BalanceArgs args)
{
// process args and produces results
}
public TransferResults TransferMoney(TransferArgs args)
{
// process args and produces results
}
…
請注意一個事實,即在Request
模式1,串Args
是一個JSON對象的JSON序列以及串Results
in Respond
結構。
例如,
request.Args
將被反序列化爲BalanceArgs
,TransferArgs
等。另外respond.Results
將被反序列化爲BalanceResults
,TransferResults
等。
感謝你指導
在此先感謝您,因此根據您的回答,最好使用簡單輸入類型的多個端點,而不是具有一個端點,但具有複雜的輸入和輸出類型。我對嗎?如果這就是你的意思,這兩種方法在性能和安全性方面是否有區別? – anonim
@anonim在這種情況下,是的。無論是在客戶端還是在有條件請求的服務器上,緩存響應都有可能的性能增強。從理論上講,緩存可以用於你的任何一種方法,但它可能會變得更加混亂。就安全性而言,除非您開始包含可由中間服務器記錄的查詢參數,並且不應包含任何敏感信息,否則我看不到任何區別。 –
如果我錯了,請糾正我。所以根據你所說的,第一種方法;具有複雜輸入類型的一個端點更好,因爲可以更容易地對其應用緩存。如果我是對的,請給我提供一些有關該主題的參考。感謝您的親切幫助。 – anonim