瀏覽標籤:

Laravel

Laravel RESTful API 送養系統 完賽結語

未來展望

感謝有鐵人賽這個機會,讓我系統產生了一個雛形,還可以分享我目前知道的所見所聞,我會繼續完成這個系統,開始動手做前端的畫面,還有把系統規劃的更加完整,幫台灣的浪浪進一份心力,減少浪浪與人類的衝突,以及浪浪過多環境衛生的問題。

題外話:小弟我想專注在後端的開發,前端想外包,但因為只是想做一個作品,正在考慮要不要花這個錢,正在想要不要前端自己切版,淘寶買素材自已用就好還是外包給設計師畫圖(想讓前端畫面好看一點),甚至考慮整個前端都外包!因為以後想朝向後端、資料庫方面發展,所以想要一部分外包,不知道怎麼做會比較好!如果有經驗的歡迎跟我分享~或對動保議題有興趣的高手,也歡迎一起來做這個專案!

閱讀更多

Laravel 自動產生API文件

簡介&安裝

我們打造好的API,沒有使用手冊,對於要介接的開發者,根本無法使用,所以必須提供文件給他們!

所以今天就來介紹 mpociot/laravel-apidoc-generator 這是搭配apidoc + Laravel路徑配置 另外寫好的套件,能夠基於 Laravel 路由自動生成專案 API 文件,可以省掉很多麻煩!

也可以使用 apidoc 官方的套件但就是需要多設定一些路徑!

GitHub連結

使用Composer安裝這個套件

composer require --dev mpociot/laravel-apidoc-generator
閱讀更多

更好的自己更好的 API – 如何安心升級 Laravel6

昨天優化API讓我們在錯誤的經驗中不斷的學習,但也因為這些經驗,可能讓我們猶豫不敢前進,這會是內心一個很大的阻力,但也是自然的保護機制!

今天會有更大的改變,建議在嘗試練習的專案中可以嘗試,或是測試環境上測試,若用於正式上線的系統,請深思熟慮!並做好備份的動作~

系統要越來越好的關鍵條件

  1. 足夠量的測試覆蓋率(核心為主的程式碼測試,例如:對Service的測試)
  2. 安全性的更新(現在的系統,功能越來越大,撰寫的過程,時常都會用到套件!使用Laravel 框架也是,每個版本都會有安全漏洞維護的期限,為了系統安全建議更新,但更新後肯定會有一些錯誤產生,確保無誤一定要有測試程式保護)
  3. 良好的撰寫習慣,符合規定的Coding Style
  4. 確認官方升級文件的項目,在目前系統可能影響到的地方,手動確認程式無誤!
  5. 在測試環境升級確認無誤,再運用在線上系統,升級前一定要備份
閱讀更多

更好的自己更好的 API

今天來優化自己的 API (順便聊聊心情人生),前幾天都是把原本既有的程式碼拆開,現在要來優化API。

直接動手做(心情分享)

今天打算修改的部分希望盡量把原本的不足,寫成符合規範的程式碼!若你懶得看心情分享!請直接跳到下方的 修改原本設計的 URI單元,馬上實現動手做的精神!

人生難免不如意去年想要參加鐵人賽,但被一些事情影響到自己的心情,實在提不起勁,什麼也都懶得做、懶得用!沒有參加到去年的鐵人賽了

(現在出社會兩年多了!說實在真的沒有比當學生開心好好把握當學生 )。

那時心情比較低落所以看了很多書呀!心理學、正念、生活品質、斷捨離… 嘗試做很多改變。

什麼都試試看!最後成效不佳,覺得自己很廢。得到最大的體悟就是 現在認為的事情不一定是對的事,因此開始有點不敢動手做,覺得成效不好,做白工的感覺!

最後實在不行,覺得太廢了!跟朋友聊聊,發現如果遇到不同意見的人,可以在自己發表意見時先聽聽對方的想法,多多少少都會感覺得出來他為什麼這麼說的原因,換位思考一下!我覺得這很有幫助~

(雖然一件事情沒有絕對的對或錯!但是總比一直在做你以為對的事情,最後成效不佳好多了!)

現在看一看鐵人賽也快撐到完賽了!雖然不到完美但有很多收穫!

全部都歸咎於開始動手做,不開始就不會有進展,很開心我對於寫程式這方面充滿這種熱情! 哈哈哈xD

朋友跟我說,人生是一個面,工作是個點,我的人生只有工作跟運動,我現在是一條線而已,非常規律、自閉。 (工程師都這樣嗎?)

親情、友情、愛情,我好像都沒有顧好! 沒有像對程式般的熱情,那種撩下去就對了感覺!

如果你是害怕寫程式,撩下去就對了!(自己期許除了程式能力方面外,也有這樣的熱情。)

秉持著撩下去的熱情做做看就對了!沒有一次就寫到完美的Code,必須要有嘗試過的經驗,還有不斷的修正。

廢話不多馬上依照我目前的經驗分享,讓API更好維護,讓程式碼更符合統一規範的過程。

正式上線系統修改變更程式前請思考清楚!

閱讀更多

讓你的程式更美好 – 重構現有的程式碼

開始重構程式碼,前幾天有提到 Controller 越來越肥大,程式碼越來越多,根本就已經超出人類想要看的範圍了!就像一篇好的文章,字數太多也是一件壞事,要有足夠的耐性才會想看。

這系列鐵人賽目前的 Controller 程式碼還不算太多,還算簡單拆開來相對容易,講解也比較清楚。

預計這樣拆開目前的 Controller

  • 驗證會員等級權限 – 已由 Policy 負責
  • 驗證使用者輸入資料 – 需再加入 Request
  • 商業邏輯或外部資源 – 需再加入 Service
  • 轉換資料結構 – 已由 Resource 負責

為了達到接近單一職責原則預計把Controller 拆成這個樣子! 降低程式之間的耦合性!對目前的程式來說比較好!檔案不會拆太多太細,又可以讓程式可讀性增加, PolicyResource 已經完成了!現在來拆解 Service驗證資料

閱讀更多

讓你的程式更美好 – Service 概念

我自己的經驗呢!是把原生的PHP轉換成Laravel框架,那個時候最主要希望可以好維護,但是,把權限啦~商業邏輯啦~全部都會寫在Controller 最後你就會發現

Controller 越來越大

Controller 越來越大

Controller 越來越大

如果又不是前後端分離的方式拆開的話,Controller 會非常非常亂。

之前就開始想辦法前後端拆開,所以開始研究RESTful API 的設計方式

閱讀更多

進階 RESTful API 討論

複習一下!並加入比較深入進階的部分,利用鐵人賽這個機會讓我再去認真查詢學習 RESTful API 的相關設計!雖然不是強制一定要這麼設計API,但是可以讓程式碼的可讀性更好!我想這是各位大大會想努力的地方。

確認一個資源

如之前的範例資源就是動物資源,設計RESTful API要先有一個客戶端資源,可以做查詢動物的資訊、建立、編輯、刪除,分別用HTTP不同的動詞,以客戶端(介接我們API的人)的方向去思考,不需要跟資料表一模一樣。

HTTP 動詞

  • GET: 讀取資源
  • POST: 新增資源
  • PUT: 替換資源
  • DELETE: 刪除資源
  • PATCH: 更新資源部份內容

GET 的動作相較安全,它不會變動更改到伺服器的資訊,主要用來查詢資料。

POST、DELETE、PATCH、PUT 則會依照對應的動詞做需要的動作,寫入資料庫,或一些商業邏輯。

一定會是這種模式 動詞+資源

POST http://127.0.0.1/animal

PUT、PATCH 差別

PUT 通常做替換一個資源功能。

PATCH 修改資源的部分內容。

我自己是這麼定義的,假設資料表內已經有一筆資料內容如下

{
  "id" : 1,
  "name" : "小白" ,
  "type" : "小型犬" ,
  "birthday" : "2019/1/29"
}

PUT : 動物資料整個替換掉 PUT 方式請求網址 /animals/1  修改編號1的資料,回傳資料內容都是ID 1但裡面的內容整個不同。

PUT下面的內容,那麼ID 1的資料就會全部被修改成小黑的資訊,所以請求的時候必須填寫所有欄位不然資料會變成預設值。

{
  "name":"小黑" ,
  "type":"大型犬",
}

--結果--
{
  "id" : 1,
  "name" : "小黑" ,
  "type" : "大型犬" ,
  "birthday" : null
}
閱讀更多

我的最愛追蹤功能製作

定義資源

我的最愛功能,製作一個可以讓 user 追蹤動物的操作,是一個連結的關係,綁定動物與用戶的關聯。

依照以前的經驗,我會幫這樣的動作取一個名字 like 之類的資料表來儲存內容。

但經過幾次的打造API經驗後,在規劃資料表的命名上,如果系統規模很大只有 like 當表名不是很明確。

我們這個系列打造的送養系統如果想要新增一個追蹤某位愛心媽媽的功能,就會覺得like不是很明確。

這樣在資料庫中看到 like 資料表,無法明確的知道內容。所以這邊我不另外給它一個名字。

會製作一張表  animal_user  這是我目前的原則!可以清楚知道這張資料表紀錄著 animal 與 user 的關係,並且依照字母排列A->Z命名這張表。 所以不命名為 user_animal 這是開始用 Laravel 後才有的習慣,在某個官方文章有寫到預設是 開頭A->Z來建立資料表。

閱讀更多

會員權限設計(管理員、一般會員)

昨天設定修改資料表以符合需求,接下來要設定權限部分,打算分兩種會員 管理員與一般會員。

權限說明
管理員可以做所有的新增刪除修改
一般會員可以新增動物而已,並且只能修改自己新增的動物。無法新增刪除修改分類

新建一個原則 policy

php artisan make:policy AnimalPolicy -m Animal
產生policy檔案
閱讀更多

修改資料表新建 migration

明天我們要來建立權限的部分,之前設定的是驗證使用者使用 token 身份,但一班的網站至少會有管理員或一般會員的區分,因此今天先來修改基本需要設定的東西。

變更資料表

資料表原本規劃時沒注意到的地方,或是規劃好的東西難免都會被要求修改需求,所以修改資料表也是一門學問,用 migration 檔案修改檔案可以方便整個團隊更新到最新的版本。

跟大家說一個經驗,如果目前的系統是在線上用運行中的,並且公司沒有 DBA 在負責管理資料庫的話,要變更資料庫欄位時一定要三思而後行。 至少要確認有沒有備份。

閱讀更多