一般來說，為了避免使用者上傳了什麼奇奇怪怪的檔案被執行，會將上傳的檔案放在網頁根目錄以外的地方，再利用 PHP 將檔案內容輸出給 Client。
最簡單的方法是用 readfile 這個函式直接將檔案內容輸出，然而如果允許上傳的檔案比較大的話， readfile 會一次將檔案讀到記憶體內，造成記憶體用量超出上限的問題。
這個不能單純將記憶體上限提高來解決，不然只要同時幾個人下載檔案就會造成伺服器記憶體用盡。我想目前最簡單的方法是利用 stream 的功能來做：
|
1 2 3 4 5 6 7 |
$srcStream = fopen($file, 'rb'); $dstStream = fopen('php://output', 'wb'); stream_copy_to_stream($srcStream, $dstStream); fclose($dstStream); fclose($srcStream); |
這樣子就可以了，經測試下載數百 MB 的檔案也不會直接造成 PHP 錯誤。
在考慮要使用 SQLite 還是其它資料庫的時候看到了這篇：http://stackoverflow.com/questions/14217249/sqlite-and-concurrency
裡面提到 SQLite 的效能最高可以達到每秒五萬筆 INSERT，但會因硬碟的性能不同而有差異。而我要使用的環境別說每秒上萬筆，一秒有上百次操作就很了不起了。
於是寫了簡單的測試，看看在我機器上跑得怎麼樣：
|
1 2 3 4 5 6 7 8 |
<?php unlink("mydb.sq3"); $pdo = new PDO("sqlite:mydb.sq3", null, null); $pdo->exec("CREATE TABLE test(counter);"); for($i = 0; $i < 100000; $i++) { $pdo->exec("INSERT INTO test(counter) VALUES($i);"); } |
本來想說每秒五萬筆的話，那我得弄個十萬筆才能執行超過一秒，結果沒想到這一跑就超過了半個小時還沒跑完。平均下來每秒只執行了 38 筆的操作。果然夢想與現實的差距就是這麼大嗎？
不可能吧。於是開始檢討差距這麼大的原因，第一個想到的是硬碟速度的問題，也確實在執行期間硬碟幾乎是一直忙碌的狀態。但我這已經是固態硬碟了，怎麼樣也不會這麼難看吧。而且這已經是少到不能再少的資料了，實際運用上一定會更多資料量的。
後來在這篇文章裡看到了 nosync 這個關鍵字：http://www.sqlite.org/speed.html
進而找到了這個說明：http://www.sqlite.org/pragma.html#pragma_synchronous
所以就開始了第二版的測試：
|
1 2 3 4 5 6 7 8 |
<?php unlink("mydb.sq3"); $pdo = new PDO("sqlite:mydb.sq3", null, null); $pdo->exec("CREATE TABLE test(counter);"); $pdo->exec("PRAGMA synchronous = OFF"); for($i = 0; $i < 100000; $i++) { $pdo->exec("INSERT INTO test(counter) VALUES($i);"); } |
只加了一行，但這次只花了不到八秒就跑完了。算一算這樣每秒就有上萬筆的操作，雖然跟五萬筆還是差了一些，但應該是很夠用了。
Zend Framework 2 有提供一個 AbstractRestfulController 用來實作 REST API。不過按照慣例，Zend Freamework 的說明文件都只是簡單帶過而已，真正的用法與規則還得去閱讀程式碼。
使用方法，就只要繼承 AbstractRestfulController 即可：
|
1 2 |
class ResourceController extends AbstractRestfulController { } |
在 Router 那邊，記得不要設置 action：
|
1 2 3 4 5 6 7 8 9 10 |
'rest_resource' => array( 'type' => 'segment', 'may_terminate' => true, 'options' => array( 'route' => '/resource[/][:id]', 'defaults' => array( 'controller' => 'ModuleNamespace\Controller\Resource', ), ), ), |
之後，就會自動對應到 Controller 的 Method：
因此，一個支援 GET 與 POST 的 Controller 大概長這樣：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
class ResourceController extends AbstractRestfulController { public function get($id) { //....... return $response; } public function getList() { //....... return $response; } public function create($data) { //....... return $response; } } |
其它沒有實作的部份，AbstractRestfulController 會幫你回應 405 Method Not Allowed 。
另外，identifier 的名稱，預設是用 “id”，為了可讀性，你也可以自訂 identifier，下面我們改用 “name” 作為 identifier：
|
1 2 3 4 |
class ResourceController extends AbstractRestfulController { protected $identifierName = 'name'; //............. } |
相對應的 Router 也需要把 id 改為 name：
|
1 2 3 4 5 6 7 8 9 10 |
'rest_resource' => array( 'type' => 'segment', 'may_terminate' => true, 'options' => array( 'route' => '/resource[/][:name]', 'defaults' => array( 'controller' => 'ModuleNamespace\Controller\Resource', ), ), ), |
AbstractRestfulController 的用法大致上就這樣。
PHP 的 include 暗藏了一些潛規則，如果沒搞懂的話，遇到問題會以為見鬼了。所以這篇主要就在研究 PHP 的 include 運作方式。
首先，我們從官方文件可以看到 include 會區分為兩種模式，一種是 include 檔案，另一種是 include 路徑。只要是絕對路徑，或是相對路徑，就是以 include 路徑來運作。這裡比較容易搞混的是相對路徑的部份，因為 PHP 只把 “.” 或 “..” 開頭的作為相對路徑看待。
因此 include “foo/bar.php” 是屬於 include 檔案，而 include “./foo/bar.php” 則是 include 路徑。
在 include 檔案時，會先從 include_path 開始搜尋，再來是搜尋此 PHP 程式所在的資料夾(the calling script’s own directory)，最後是搜尋 current working directory(CWD)。
而在 include 路徑時，則只會從 CWD 去搜尋。
為了驗證，我設置了這樣的環境來作測試：
|
1 2 3 4 5 6 7 |
/calling/include_priority.php /calling/library/libxx.php /calling/library/libyy.php /cwd/library/libxx.php /cwd/library/libzz.php /cwd/library/libyy.php /inc_path/library/libxx.php |
其中 lib{xx,yy,zz}.php 的內容都是一樣的：
|
1 2 |
<?php echo "included " , __FILE__, "\n"; |
include_priority.php 是將要執行的主程式，分別將 include_path 以及 CWD 設置到 inc_path 與 cwd 資料夾，這樣就能分辨優先順序，其內容是：
|
1 2 3 4 5 6 7 8 9 10 11 12 |
<?php set_include_path(__DIR__ . "/../inc_path"); chdir("../cwd"); include "library/libxx.php"; include "library/libyy.php"; include "library/libzz.php"; echo "------\n"; include "./library/libxx.php"; include "./library/libyy.php"; include "./library/libzz.php"; |
最終結果是這樣子：
|
1 2 3 4 5 6 7 |
/inc_path/library/libxx.php /calling/library/libyy.php /cwd/library/libzz.php ------ /cwd/library/libxx.php /cwd/library/libyy.php /cwd/library/libzz.php |
由結果來看，符合文件中所描述的運作方式。
接著來驗證第二種情況，如果 a.php include b.php 且 b.php 又 include c.php 的話，那麼在排除 include_path 與 CWD 的情況下，會如何運作？
環境設置：
|
1 2 3 4 |
/library/libxx.php /root.php /sub/sub.php /sub/library/libxx.php |
root.php 是主程式，內容為：
|
1 2 3 |
<?php set_include_path("/no/such/dir"); include "sub/sub.php"; |
sub.php 的內容：
|
1 2 |
<?php include "library/libxx.php"; |
libxx.php 的內容與前一個實驗相同。
最後的輸出結果是：
|
1 |
included /sub/library/libxx.php |
由此可見程式所在的資料夾(非CWD)是會隨著 include 所在的檔案而變動的。換句話說，就是以這一行 include 語法所在的檔案的位置為主。
綜合以上的內容，就可以解釋下面這個看到鬼的例子了：
|
1 2 3 4 |
/root.php /sub/sub.php /sub/library/libxx.php /tools.php |
在 root.php 裡面 include 了 sub.php 檔案：
|
1 2 |
<?php include "sub/sub.php"; |
然後在 sub.php 裡面又分別 include libxx.php 與 tools.php 兩個檔案：
|
1 2 3 |
<?php include "library/libxx.php"; include "../tools.php"; |
因為 include “library/libxx.php” 成功了，於是以為相對路徑是由 sub.php 所在位置來計算，因此又下了 include “../tools.php” 這樣的指令，結果死的不明不白。
其實 libxx.php 是以檔案的方式去 include 的，所以會搜尋三個地方：include_path，sub.php 所在的位置，以及 CWD。而 sub.php 所在的位置剛好就可以找到 library/libxx.php 這檔案，所以 include 成功。
在 include tools.php 時則是因為它以 “..” 開頭，所以只會從 CWD 來計算相對路徑找檔案。而此時的 CWD 是在 root.php 那邊，自然就找不到東西了。