向後台發送請求，後台將會做出相對應的回應。
- 後台位置 https://dinnersystem.com/dinnersys_beta/backend/backend.php
- 你可以採用
get或是post進行傳輸
呼叫方法
- URL Suffix
?cmd=login&id={your_id}&password={your_password}&device_id={device_id}- 例如
?cmd=login&id=seanpai&password=131313&device_id=HELLO_FROM_ANDROID回傳
- 一個使用者
json物件附註
device_id其實並沒有限制，只是方便識別哪一種應用程式登入系統而已- 系統不限制一隻帳號同時能有幾個人登入
- 登入失敗會被記載到
error_log中，某隻帳號登入失敗太多次會被鎖- 更改密碼後，並不會強制要求使用者跳出系統
呼叫方法
- URL Suffix
?cmd=logout- 例如
?cmd=logout回傳
Successfully logout.呼叫方法
- URL Suffix
?cmd=change_password&old_pswd={old_password}&new_pswd={new_password}- 例如
?cmd=change_password&old_pswd=5487580&new_pswd=5487580回傳
- 一個使用者
json物件附註
- 密碼打錯並不會被記錄到
error_log，可以嘗試無限次
呼叫方法
- URL Suffix
?cmd=show_dish- 例如
?cmd=show_dish回傳
- 菜單的
json陣列附註
- 取得剩下多少餐時，採用
S鎖進行上鎖，增加資料庫效能- 人氣餐點的判斷是經由
regex來判斷的，如果餐點名稱被regex判斷為真，則該餐點屬於人氣餐點
呼叫方法
- 請自行組合 URL Suffix
- 較常使用
限制要抓出哪些資料
?cmd=select_{self, class ,other ,factory}
self僅限抓出自己的資料class僅限抓出自己班的資料other不限制，不要問我為什麼叫做otherfacto僅限抓出自己廠商的資料時間上界
?esti_start={Year/Month/Date-Hour:Minute:Second}時間下界
?esti_end={Year/Month/Date-Hour:Minute:Second}取得實際歷史資料
?history={true}
- 較少使用
抓出特定使用者的
?user_id={user_id}只抓出自己的
?person={true}只抓出自己班的
?class={true}點單編號
?oid={order_id}廠商編號
?factory_id={factory_id}
- 例如
?cmd=select_facto&esti_start=2019/01/01-00:00:00&history=true回傳
- 點單的
json陣列附註
- 取得是否繳款時，採用
S鎖進行上鎖，增加資料庫效能- 由於餐點名稱、金額會變動，取得實際歷史資料才能得到真正的資料，但是效能會較慢
呼叫方法
- URL suffix
?cmd=make_self_order&dish_id[]={dish_id}&time={Year/Month/Date-Hour:Minute:Second}- 例如
?cmd=make_self_order&dish_id[]=1&dish_id[]=1&time=2019/06/07-00:00:00回傳
- 點餐資料的
json物件附註
- 取得剩下多少餐時，採用
X鎖進行上鎖，確保資料庫一致性- 遇到資料庫死結時，直接回傳
database deadlock呼叫方法
- URL suffix
?cmd=delete_{self, everyone}&order_id={order_id}
self意思是指能刪除自己的點單everyone意思是能夠刪除任何人的點單
- 例如
?cmd=delete_self&order_id=5487回傳
- 被刪除那個點單的
json物件附註
- 改變剩下多少餐時，採用
X鎖進行上鎖，確保資料庫一致性- 遇到資料庫死結時，直接回傳
database deadlock- 資料庫並不會真的刪除那筆資料，而是在欄位中標記為
deleted
呼叫方法
- URL suffix
?cmd=set_payment&password={password}&order_id={order_id}&target={true,false}- 例如
?cmd=set_payment&password=5487&order_id=6969&target=true回傳
- 被繳款點單的
json陣列附註
target = true代表標記為有付款target = false代表標記為尚未付款- 改變付款狀態時，採用
X鎖進行上鎖，確保資料庫一致性- 遇到資料庫死結時，直接回傳
database deadlock
呼叫方法
- URL suffix
?cmd=get_pos- 例如
?cmd=get_pos回傳
- 一個使用者
json物件附註
- 飛宇的系統如果出問題，回傳
pos is dead
呼叫方法
- URL suffix
?cmd=update_dish?id={dish_id}?dish_name={dish name}?charge_sum={charge}?is_vege={MEAT ,VEGE ,PURE}?is_idle={true ,false}'?daily_limit={廠商一天能供應多少量}
- 例如
?cmd=update_dish&id=1&dish_name=Fei Yu GGYY&charge_sum=87&is_vege=MEAT&is_idle=true&daily_limit=-1回傳
Successfully updated food.附註
daily_limit設定為-1代表不限制
基本上所有的回傳 json 都是點單資料的子集，在此僅展現點單資料的資料格式
命名原則應該是非常清楚，僅對可能有疑惑的部分進行解釋
order_maker是痕跡功能，代表是誰代替使用者點餐的- 登入時，
user會有額外的欄位，叫做valid_oper，代表使用者可以對後台進行什麼操作
{
"id":"38930",
"user":{
"id":"-1",
"name":"-",
"daily_limit":"",
"vege":{
"number":"-1",
"name":"unknown"
},
"class":{
"id":"-1",
"year":"-1",
"grade":"-1",
"class_no":"-1"
},
"seat_no":"-1",
"prev_sum":"0",
"money":"",
"card":""
},
"order_maker":{
"id":"-1",
"name":"-",
"daily_limit":"",
"vege":{
"number":"-1",
"name":"unknown"
},
"class":{
"id":"-1",
"year":"-1",
"grade":"-1",
"class_no":"-1"
},
"seat_no":"-1",
"prev_sum":"0",
"money":"",
"card":""
},
"dish":[
"1"
],
"money":{
"id":"38930",
"charge":"40",
"payment":[
{
"id":"154769",
"paid":"true",
"able_dt":"2019-02-25 00:00:00",
"paid_dt":"2019-02-25 09:29:04",
"freeze_dt":"2019-02-25 10:30:00",
"name":"payment",
"reversable":"0"
}
]
},
"recv_date":"2019-02-25 12:00:00"
}命名原則應該是非常清楚，僅對可能有疑惑的部分進行解釋
bank是連結pos系統的設定檔- 在
{login ,payment}.time的時間內，密碼驗證失敗了{login ,payment}.tolerance次，就會鎖定{login ,payment}.punish秒，login與payment的失敗次數、懲罰時間分別計算 announce是因為飛宇的系統太容易掛掉了，所以每次系統掛掉聊天機器人會去聊天室提醒大家系統掛了
[
"bank" => [
"ip" => "192.168.0.2",
"port" => 8787,
"password" => "Fei Yu GGYY"
],
"database" => [
"ip" => "localhost",
"account" => "dinnersystem",
"password" => "########",
"name" => "dinnersys"
],
"login" => [
"time" => "60",
"tolerance" => "3",
"punish" => "60"
],
"payment" => [
"time" => "60",
"tolerance" => "3",
"punish" => "60"
],
"announce" => [
"url" => "www.google.com",
"auth" => "##############"
]
]
- payment 資料表中的 tag 分為五種 {user ,dinnerman ,cafeteria ,factory ,payment}
- cafeteria 代表合作社收到實體錢，也就是代表這份點單是成立的；payment 代表是合作社收到虛擬錢，也代表這份點單成立。
- (cafeteria = true OR payment = true) 的點單就是成立的點單，其餘都是不成立的。
無法更新菜單
- 詢問廠商是否有錯誤訊息
- 去看資料庫的 error report 表格
- 檢查有沒有匯入 SQL Procedure (Morgan 就是你!)
系統無法連線
- 確認 dns 解析正常
- 確認有開啟 Nginx MySQL PHP
如果 App 一打開就 crash
- 確認 u_move_u_dead 存在於 frontend
- 確認 version.txt 存在於 u_move_u_dead
- 看 Crashlytics 裡面有沒有輸出
PHP 抓不到正確的 session
- 試試看登入 ssh 的 domain name
附註
- pos 掛掉，午餐系統也很容易連累掛掉，跟其他伺服器溝通是很耗費效能的事情
- 如果還有遇到什麼問題，請聯絡我，我會再把東西寫入問題集
編寫的文件不可能 100% 詳盡，有問題自己去翻原始碼找答案。
編寫於 2019/06 ，如有問題，請用 github 聯繫我。白翔云，別再靠北我不寫文件了