最近對service的api設計，在team內有些討論，主要集中在api是足夠抽象、通用好呢， 還是具體、易用好？
其實這個是要折衷的，通用的好處是以後更改api的可能性小，但壞處是想要通用，裡面的字段就不能定義太死，不定義死，極端的例子是全部用name/value pair，最通用，但client面對這些nv，根本不知道怎麼去設值，這樣的api很明顯是不友好，難用的，而乙個好的api應該是自明的（self-documenting）的。 所以需要折衷。
關於api 通用性（generic）和 自明性（self-documenting）討論繼續...
再看乙個場合，公司a和公司b合作，a需要提供一組api給b公司條用，好吧，b公司，我們決定使用世界上最通用的api給你用，www.a.com/service4b，可是裡面的request body要怎麼寫呢？像這樣針對性不叫強的api，最好還是具體一點，這樣client看到你的介面，就基本知道要怎麼呼叫你的服務了, 比如對於查詢合同的api，你就必須要在http body裡寫明:
123456
或者用rest的思想，uri為 www.a.com/service4b/contract/123456. 這樣的api失去了通用性，但其專用性以及對特定環境下的約束，正是b公司我們想要的。
還有api也是乙個不斷演化的過程，所以不用太擔心當前的api是不是擴充套件性太差，這也是agile的思想，包括http從1.0 到1.x 也是在不斷的演化當中。
當然乙個企業級api需要考慮的因素還很多，這裡先開個頭，後面會結合公司的commerceos （ebay next gen public api)，在詳細討論....
還有個原因就是，剛才看到一篇文章《管理企業級api的7個最佳實踐》，覺得說的還是很在理，先copy在這裡，後面有時間再整理一下。
1. api優先的設計方法
soa最佳實踐就是將api開發從後端應用中完全地分離出來。「與其在執行應用之後再建立api，倒不如先盡己所能提前建立好乙個介面，然後再將其與後端邏輯相掛鉤。這樣一來，問題便可逐個擊破，開發者也可以更專注於清晰明了的api執行過程，而api測試也會變得更加容易。」shafii如此說道。
2. 選擇乙個穩定的api執行時
執行時的選擇可以說是至關重要。因此，我們必須要注意乙個企業級api從建立開始的所有需求，比如可擴充套件性、實用性、可靠性等。即使api沒有進行修改，也應該能夠在企業內部和雲端順利執行。這樣一來，開發者便可以幹很多事情，比如利用雲來獲取更多額外資源，或者在充分準備之後，實現企業模型到雲模型的轉移等。
3. 建立乙個**服務儲存庫
另外乙個關鍵點就是將api開放到乙個**儲存庫中，以便於開發者和終端使用者發現。
4. 通過版本、策略和契約來管理服務
對於任何作業系統或應用程式來說，api的版本控制都是必不可少的，其重要程度不亞於安全性和策略管理。
5. 提公升和開放你的api
shafii強烈建議為api建立乙個社群平台，並為其提供資訊和技術支援。
6. 通過度量、分析來監控和測量api使用情況
在商業活動中，評估力度越大，就越能有效追蹤到api的執行過程和結果。不管是從潛在的技術層面還是商業層面，一定的度量標準都會幫助開發者更好地了解api的使用情況。
7. 重構api以提公升api使用者體驗和效率
對於這最後一點，shafii更是反覆強調，一定要對api保持不斷的更新。
iOS企業級架構設計
對於單獨的小型應用能處理好各部分的功能，處理好各部分分層的業務邏輯已經實屬不易。因為模組與模組之間的耦合不易拆除，隨著業務的增長，當初嚴格的劃分已經越來越不能滿足要求，模組開始變得異常膨脹，邏輯也異常的冗餘。乙個好的架構應該能解決這些棘手的問題，乙個好的架構的機制一旦被確定，就不應該輕易更改。對於乙...
企業級鍊錶設計思路
define crt secure no warnings include include include 節點結構體 struct linknode 鍊錶結構體 struct llist 取個別名 typedef void linklist 鍊錶的初始化 返回鍊錶結構體 linklist init...
SpringBoot企業級框架
zebra 微服務框架 springboot zebra4j是一款使用sping boot特性全新開發的微服務web框架，嘗試封裝一些常用框架比如dubbo等作為spring boot元件，結合微服務的框架思想，利用nodejs zebra4js作為應用閘道器，使得各個功能分層服務，持續迭代，解放團...