很高興有人能看到這篇部落格!我希望你已經做好心理準備,在這裡我們将從0開始建構REST API。這不是一件簡單的事情:我們接下來要做很多事情,不僅僅是coding還包括去理清一些理論知識。但我向你保證,你會為你付出努力而感到高興。
接下來,我們會學習REST的一些理論并遵循 best practices 去開發,但也不會墨守陳規。因為如果你固執于太多的條條框框,就可能會被這些繁文缛節所困擾。建構一個完美的RESTful API是不太可能的,這反而會引起更多的麻煩。
是以,一個友好的API更符合實際,我們會遵循REST的最佳部分,而當我們違規或糾結時會告訴你。我們不會在意那些細節。不,這隻不過是在攻擊API中那些醜陋的地方,比如如何定義方法以及文檔應該儲存哪裡,為什麼等等。
開發項目: Resources and Links
項目?代碼大戰( Code Battles):一個超級牛逼的網站,程式員與項目進行着殊死搏鬥。當你注冊之後,你可以建立一個程式員,并為他選擇頭像。
REST的思想在于資源(resources)。好,我現在說的是資源(resource)!一定要清醒。這對REST是非常重要的,這裡醉了的話,你将通不過第二章。表示法(representations)同樣如此。
你可以對這個程式員resource進行某些操作,比如充電。基于運氣因素,這可能會增加或減少程式員的等級,接下來還可以去戰鬥,和項目去進行戰鬥,項目又是一個resource。我們的程式員終究會取得戰鬥的勝利,戰鬥同樣也是一個resource。
接下來,我将解釋下他們明明看起來很自然,而要說他是資源(resource)。
我們項目的計劃是建立一個API允許HTTP用戶端可以完成上述這些操作甚至更多。但是建立和編輯程式員的請求位址是什麼樣子?用戶端以JSON形式把資料發送給我們,我們是不是也應該以JSON傳回資料?我們怎麼樣驗證錯誤,進行查詢的url又如何定義比如程式員清單和程式員詳情HTTP,那麼HTTP methods 和狀态碼呢?我們怎麼把這些都記錄下來呢?用戶端怎麼知道建立程式員需要哪些字段?通過哪個URL去和項目戰鬥?
噢,好多。。。是以建構一個可用的,一緻的API所涉及的不止是定義一個請求位址,但也正因如此,你在這裡,一起繼續吧!