1) 航司傳統(tǒng)PSS與GDS的數字化轉型是大勢所趨橘霎，但是路漫漫其修遠兮。雖然航空業(yè)擁有較高的IT和信息化水平厂抖，但是固有的業(yè)務壁壘往往不能讓新的IT技術和思路，尤其互聯(lián)網的理念得到很好的發(fā)展克懊。同時雖然IATA推出NDC及ONE Order很久了忱辅，但是真正業(yè)界的投產七蜘，個人感覺還趕不上區(qū)塊鏈的半年的演變。
2) 同時由于國內草臺班子式的開發(fā)團隊和IT理念與國外的不同墙懂，就對于最簡單橡卤，已經有近乎20年的Web Service還重復著不知所云的忽悠，把SOA损搬，ESB碧库，REST，微服務巧勤，Serverless等等混為一談嵌灰，以為做個Spring Framework的RESTful API就能夠微服務了。而忽略了各個技術概念的本質和核心思想颅悉，更忽略了上面這些都是概念和架構思想沽瞭，更忽略了與其相輔相成的一些設計理念，例如DDD等剩瓶。
3) 更有甚者認為微服務在航司的應用就是IATA的NDC了驹溃。做些RESTful API就是微服務了。
這篇和后續(xù)文章主要描述個人認為在航司投產一些服務化產品延曙，尤其參考NDC規(guī)范和IT理念的關鍵技術思路（注：不包含任何航司電商內部業(yè)務實現(xiàn)和傳統(tǒng)PSS轉型的內容）
Web Service
Web Service, 在國內被翻譯成“Web服務”豌鹤，“網絡服務”....等等，我還記得研究生畢業(yè)的時候被導師折磨了半天枝缔，要我明確和清晰的翻譯“Web Service”布疙。但是我還是奉勸各位，對于國外這些技術術語還是老老實實用英語吧魂仍，什么SOA拐辽，ESB，REST等等擦酌，能不翻譯就不翻譯俱诸，翻譯了之后反而喪失了其含義，同時讓“年輕人”更迷惑赊舶，搞的他們貌似懂還裝專家睁搭，其實自己都沒搞明白是什么。
各位有興趣還老老實實看看Wiki的翻譯吧笼平，最好不看百度百科：
Two major classes of web services:
a）REST-compliant web services, in which the primary purpose of the service is to manipulate XML representations of?web resources?using a uniform set of "stateless" operations;?
Web service?APIs?that adhere to the?REST architectural constraints?are called RESTful APIs.
b) arbitrary web services, in which the service may expose an arbitrary set of operations.
—W3C, Web Services Architecture[2]
https://en.wikipedia.org/wiki/Web_service
https://en.wikipedia.org/wiki/Representational_state_transfer
就這副圖而言园骆，其清晰的描述了兩種不同的Web Service的特點，如果只針對HTTP通訊協(xié)議寓调，其只有一輕一重锌唾，一通用一專用的區(qū)別。但是擺脫HTTP協(xié)議，那么RESTful API就無能為力了晌涕。
Web Service不僅僅是HTTP滋捶，更關鍵的是Contract/契約
那對于IATA的NDC的規(guī)范，一個Order Management服務從IT的角度拆解為如下內容余黎。
傳統(tǒng)Web Service應用場景
如下所示重窟，一個Web Service的描述性文件WSDL包含一系列強制的信息，其能夠更規(guī)范性和清晰的描述數據傳輸的規(guī)范和要求惧财。
個人認為巡扇，對于航司這種復雜的業(yè)務及數據交換，在內部垮衷，其實很多時候在對外發(fā)布的場景厅翔，傳統(tǒng)的Web Service擁有獨一無二的優(yōu)勢。
所以不要以節(jié)省幾行代碼帘靡，或快速上線為理由知给，直接就RESTful API了。那未來的維護描姚，服務治理及管理等等可不是節(jié)省下來的這點時間能夠解決的涩赢。至少你還要寫接口文檔吧，至少你還要給別人寫調用案例吧轩勘，只要你還要處理輸入異常吧筒扒，你變化contract信息也還要考慮下游消費者吧.....
同時各位也能夠體會到，即使RESTful API绊寻，現(xiàn)在也慢慢更關注Contract First方式了花墩，例如Swagger，更例如之前WADL澄步。
還有人說RESTful API能夠減少傳輸的數據量冰蘑，但是你需要想想，對于企業(yè)內部村缸，乃至外部很多場景祠肥，帶寬及數據量能造成多大的性能壓力，就為了區(qū)區(qū)幾十個字節(jié)和幾十毫秒的性能梯皿，就丟失了數據的精度仇箱，類型等等元數據信息是否值得。
所以“沒有規(guī)矩不成方圓”东羹，Contract/契約的重要性在Web Service領域不言而喻剂桥，即使20-30年前的串口通訊，大家都還定義和遵守數據交換規(guī)則了属提。
永遠Contract First
盜用很久很久之前自己畫的一幅圖权逗，當初缺失深惡痛絕WSDL，WSDL First，看到哪些Code First的開發(fā)模式和項目欣喜若狂斟薇。
但是隨著近10年的項目經驗火惊，真心感覺現(xiàn)在越來越需要Contract First。從之前的WADL到Swagger奔垦，都在規(guī)范化接口規(guī)范。
因為再如何Code First尸疆，實際生產環(huán)境下椿猎，再有好的接口文檔，都還是需要代碼進行數據的校驗寿弱。那為什么不從一開始就把這些基礎的是做好呢犯眠？？症革？
當初Web Service的開發(fā)時候感覺Microsoft和其WCF等的限制太強筐咧，但是回過頭來看看，現(xiàn)在RESTful API的框架和代碼結構噪矛，未免太開放了量蕊。Web Service終究是“Interface”，“Interface”定義的就是規(guī)范艇挨。其實沒有多少創(chuàng)造性而言残炮。你們看看大量的公司，安排寫接口的人都是怎樣的水平缩滨，就是在拼勞動力势就。那為什么不標準化的方式，將框架建好脉漏，讓這些勞動力就只關心他能關心和掌控的那些苞冯。
讓所謂的架構師，設計人員侧巨，將“Interface”定義好舅锄，讓測試，下游系統(tǒng)能夠在定義文檔后同步開展工作刃泡。不僅僅節(jié)省時間巧娱，更關鍵的是使得設計即為交付和評審依據。
