Tag: rest

HTTP/1.1 與 HTTP/2 的最佳化技巧

這篇在討論，無論是 HTTP/1.1 時代，或是 HTTP/2 時代下 (裡面還包括了 HTTP/2 的 Server Push)，各種讓下載速度最佳化的技巧以及造成的複雜度：「Performance testing HTTP/1.1 vs HTTP/2 vs HTTP/2 + Server Push for REST APIs」。

文章裡其中一個提到的是各類「打包」的技巧，也就是 JavaScript 的 bundle，或是 CSS 的 Image sprites，甚至是 API 的合併，像是很多人會考慮的 GraphQL。

雖然在 HTTP/2 年代我們常說可以省下來，但這並不代表「打包」在 HTTP/2 情境下沒有效果，只是改善的幅度比較少，所以這個最佳化的技巧比起 HTTP/1.1 年代，可以放到後面一點再做，先把人力放到其他地方。但如果團隊工具已經熟悉打包技巧的話 (可能是以前就已經做好了)，其實繼續使用沒有太大問題...

另外是 Server Push 的情境，意外的反而可以提昇不少速度，看起來主要是少了請求的時間，所以快不少。

再來是跨網域時 CORS 的問題，在 Flash 的年代是一個 crossdomain.xml 解決，但現在的解法是多一個 OPTIONS request，反而造成很大的效能問題... 文章裡提到現在看起來有個 Draft 在發展與 Flash 類似的機制：「Origin Policy」。

作者在測試完後得到的結論其實跟蠻多「直覺」相反的：

  • If speed is the overriding requirement, keep using compound documents.
  • If a simpler, elegant API is the most important, having smaller-scoped, many endpoints is definitely viable.
  • Caching only makes a bit of difference.
  • Optimizations benefit the server more than the client.

維基百科每天的 PageView 數據 (2015/07/01 開始)

不只是維基百科，還包括所以維基基金會的專案都可以查到，精確度可以到每日。

MediaWiki 系統提供的 API 在維基基金會上的專案都關掉了。主要是因為維基基金會的專案量太大，前方有大量的 cache 擋住，後端能提供的資料其實沒有意義。取而代之的是另外規劃出來的 API。

API 的介紹說明在「Analytics/PageviewAPI」這邊可以看到，官方所提供的完整 API 說明文件則可以在「Wikimedia REST API」這邊查到。

實際測試發現資料從 2015/07/01 開始，每日更新的速度還不錯，像是 UTC 還是 2016/07/31 的現在可以取到 2016/07/30 的資料了。舉例來說，想要拉中文版 Kalafina 在 2016 七月由人閱覽的資料：

https://wikimedia.org/api/rest_v1/metrics/pageviews/per-article/zh.wikipedia/all-access/user/Kalafina/daily/20160701/20160731

如果是想拉日文版的就換成 ja.wikipedia：

https://wikimedia.org/api/rest_v1/metrics/pageviews/per-article/ja.wikipedia/all-access/user/Kalafina/daily/20160701/20160731