從WordPress REST API到WordPress Compatible

去年底WordPress 4.7熱鬧登場，在諸多熱辣辣的新功能中，要算將WP REST API納入核心使得人人有REST API用，影響最為深遠了。這代表往後任何人只要實作了與此API溝通的app，自動就有像天上星星那麼多的WordPress網站是你的潛在用戶；討厭php嗎？理論上你可以用任何你喜歡的toolchain實作這個API，那些透過此API與WordPress網站溝通的app，自然而然就能用在你的網站上。(不過後者恐怕還要等使用者認證、授權等API穩定後才較實際)

其實這不是什麼新概念，所謂interface as contract的概念早在web前就有了，令人想哼起經典老歌：Everything Old is New Again:

之所以放在WordPress上好像鑲金了，主要還是『像星星這麼多』這件事，造成它不容忽視的影響力。看看那個知名的content injection漏洞吧！甫一露出就十幾萬網站爆炸呢 ^.<

像星星一樣，到底有多少？

在寫這篇的時候，w3techs的content management system使用分佈報告顯示，使用WordPress作為CMS的網站高達27.5%：

而且第二名與其差距不是幾趴而已，而是24.2%之多。那今日有多少網站呢？根據internet live stats，目前能追蹤的數量超過10^9，因此27.5%就有超過2.7億個網站。雖然說w3tech和internet live stats追蹤的網站集合極有可能不同，但在這樣的數量級下，個人覺得忽視無妨。

從WordPress API到WordPress Compatible

前面提到，這其實就是一個interface as contract的概念。這裡的contract就是一紙input -> output的合約，約定好後，我後端不必管你前端是JS還是mobile app，我前端也不必管你後端是PHP還是一隻猴子。有參與過提供local server讓front-end可以離線開發的專案嗎？差不多就是這個意思。

WordPress雖然勢力龐大，十多年來累積不少成就，但也有不少歷史包袱，例如你要用舊有的the loop來打造一個single page app theme幾乎是不可能的任務；要重新用更新的技術打造WordPress core也很艱困，畢竟面對的可是超過2億個網站。這就好像JS一堆很爛很莫名的feature，制定ES6仍然必須把『don’t break the web』放在第一位考量，與其刪去，不如鼓勵大家使用新的替代方案，期待十年二十年後deprecated features自然消失。

想像看看，如果WordPress core API發展成熟，替代了任何現有路徑，成為了最主要的與WordPress site溝通的橋樑，會發生什麼事？Theme developers、front-end developers、app developers等用戶端的開發者可以用任何喜歡的工具開發，而且產品立刻就有超過兩億的潛在用戶。Backend developers可以用任何喜歡的工具開發，而且自然而然就會有各式各樣的theme、各式各樣的app可以使用。

我個人認為這就是把WordPress REST API整入核心的真正意義：逐步發展這層『contract』，待其完備之日，WordPress就會從一個CMS進一步抽象成為一個CMS API spec。屆時『WordPress compatible』與否，對使用者的影響力可能會像以前的顯示卡有貼『OpenGL compatible』與否一樣強。而我們今日熟悉的WordPress，則會成為『以PHP + MySQL的經典WordPress實作例』；人們不再需要受限於此種實作，也就間接為過去的歷史包袱解了套。

這一天快到了嗎？

聽起來好棒棒，但個人覺得這一天還不會太快來到。首先，目前進入核心的只有content API，也就是存取posts / pages、comments、media libraries等等內容的API，目前REST API仍然只能用cookie authentication；沒有authentication / authorization API，應用的範圍就十分受限，以上WordPress compatible之類大夢是無法實現的。再來，就我所知範圍，擴充REST API並非下一個版本核心開發的首要任務，補上這塊缺片的日期便更加遙遙無期。

總之，從API-based theme開始吧！

要推動API完備乃至實現WordPress compatible，首先就是要有愈來愈多的WordPress API應用。考量cookie-based authentication的限制，個人覺得首選、也是最有價值的，就是API-based theme。在content API還是WP REST API plugin的時代，已經有一些不錯的實作例，例如Wallace和wp reset theme。我還有看過把twenty-seventeen theme用core API重寫的實驗，可惜好像沒繼續做了，只剩下一個tweet中的一張截圖供人瞻仰。

改用content API開發theme，代表你可以大方使用React、Angular、Elm等時下最潮到出水的碗糕來開發；與REST API溝通較為自然的async data flow，也通常代表你的theme互動性更佳、有更好的使用體驗。而且你的程式碼架構不再會受限於the loop，可以自由使用你喜歡的方式來組織。

『呃？這是要我去寫JS嗎？』很遺憾，以現在的環境，JS儼然就是今日的web machine code，就算你用elm之類的語言，由於最終還是會compile成JS，懂些JS終究是好的。Matt Mullenweg也曾在2015年WCUS keynote說：『Learn JavaScript, deeply.』，明確呼籲WordPress社群是時候跟上這個擋不住的潮流了。我碰過蠻多theme developer是幾乎不碰JS的，所以我了解，這件事對很多人來說一點都不有趣。但我相信這一定是WordPress theme未來的發展趨勢，不趁現在一切尚未蓬勃發展前強忍嘔吐上手，更待何時？