我正在嘗試評估.NET中API開發的不同Web服務框架。到目前爲止，我一直在尋找的框架是：如何評估Web服務框架
我試圖找到之間的一些共同的談話點框架，所以我知道在選擇框架時要查找什麼。到目前爲止，我已經得到了談話要點是：
任何人都可以想別的我應該考慮一下？在研究結束之前，我希望詳細地寫下每個框架，並對爲特定目的選擇哪個框架進行比較。任何幫助將不勝感激。
端到端生產力 - 核心本質的服務是提供服務，最終提供一定的參考價值的消費者。因此，消費服務的端到端生產力也應該被強烈考慮，因爲服務可以從客戶那裏獲得消耗，並且最少消耗它們，最終爲客戶提供更多的價值，這通常比開發的生產力更有價值服務本身，因爲它的價值倍增在其多個消費者。隨着許多服務的不斷髮展，更新服務的開發工作流程以及確定發生了什麼變化的容易程度（即他們是否擁有靜態API）也會影響客戶端的生產力。
互操作性 - 服務的另一個目標是互操作性和如何服務可以從異構環境中被消耗掉，大多數Web服務框架只是做HTTP然而，在許多情況下，在Intranet環境下發送API請求通過MQ是比較合適的它比HTTP提供更大的恢復能力，時間解耦，自然的負載平衡，解耦的端點，改進的消息工作流程和錯誤恢復等等。還有許多企業（和企業產品）仍然只支持或強制SOAP，因此具有SOAP端點和支持XSD/WSDL元數據也是有價值的。
可用性 - 某些API設計自然更適合於版本控制，其中可以在不破壞現有服務使用者的情況下增強防禦性服務。
可測試性和可模擬性 - 您還需要比較服務可以測試和模擬的難易程度，以確定創建集成測試的難易程度，以及它是否需要新的知識和基礎設施以及如何輕鬆它支持並行客戶端開發，當前端和後端團隊開發並行解決方案時，並行開發服務的API合約可以在開發之前設計並達成一致，以確保其在實施前滿足必要的要求，然後前端和後端團隊可以彼此獨立地實施它們。如果服務尚未實施，那麼客戶需要「嘲笑」服務響應直到他們擁有，然後在實施後才切換到使用真實服務。
學習能力是多麼直觀的開發服務，認知和概念上的開銷所需的量還影響生產力和推理服務框架的工作原理和它做什麼對你的解決方案的整體複雜性和衝擊的能力您的團隊有能力做出明智的實施決策，這些決定會影響性能和可擴展性，並需要您努力幫助新開發人員學習您的解決方案。