PHP伺服器端API原理及示例講解 介面開發

2021-09-07 17:53:25 字數 1572 閱讀 6139

但是現在的情況反過來了,我們要開發php伺服器端的api介面,也就是別人請求我們,我們驗證請求合法性,並查詢資料返回。

本文簡單講講伺服器端驗證請求合法性的方法,和接收引數的方式。

簡單的get請求如:請求這個**會返回一些資料,無論是誰用什麼程式語言請求都能得到資料。

那麼在需要驗證合法性的情況下這樣顯然是不行的。所以需要乙個秘鑰,這個時候往往用post方式請求url。

比如傳遞的引數中有個簽名sign,值是98888,當然生成sign的方式很多而且不可能這麼簡單,這裡只是隨便寫,那麼伺服器端接收到sign是98888,假如我們約定98888就是合法的,這個時候判斷sign是否為98888就可以驗證這是合法請求了。

但是這樣也太簡單了,一下子就被破解了,設定這個sign就毫無意義了。所以要有乙個生成sign的規則,請求的時候根據這個規則生成sign傳參,伺服器端接收的時候也根據這個規則生成sign,如果生成的sign一致,表明這是合法請求。每次請求都會帶上sign進行驗證。

還有一種驗證叫token,第一次請求的時候驗證token,在一定時間內不用再次驗證。這要分兩步,第一步先請求獲取token的介面得到token,第二步才是請求具體介面的功能,需要帶上token傳參。由於第一次請求token的時候,伺服器端先把token儲存起來了再返回的,所以後面的請求判斷傳過來的token是否存在就可以驗證了。

許多介面開發都同時使用兩者方式保證私密和安全。

還有一點,傳送post請求往往使用php的curl模組,比如對方通過curl傳送post請求,curl_setopt($ch, curlopt_postfields, $post_string),這裡$post_string是傳php陣列的形式好,還是json格式呢?

如果是傳php陣列,我這邊直接$_post[『xx']獲取引數,如果是傳的json格式,我這邊好像要用file_get_contents(『php://input', 『r')獲取傳過來的json資料,然後解析json得到引數。

什麼情況下用第二種?

對php來說 json和陣列有時候真的只是一行**的區別,如果我寫可能直接回用第一種。

我覺得你想你的**簡潔一點可以用第二種,我記得weixin的php sdk好像類似就是第二種(當然那是xml格式)

還有如果對方使用物件導向直接序列化出來的json的話,用json會讓他的**更簡潔一點。

第一種做法,是傳輸的是form表單post協議,php會把php陣列變成http表單的格式,跨語言通用,但是這種並不是主流的api協議,而更像是模擬提交表單。

絕大多數api協議會用json post,

第二種做法,即在http body裡放json資料。也是跨語言的,但作為api更友好。

第一種方法,直接php curl,如果資料內容沒處理好,陣列value裡傳了 @/***/*** 這樣的內容,curl會把伺服器上的本地檔案傳出去,注意防範。

x-www-form-urlencoded是rfc標準,沒什麼不相容的,豈止跨語言,還跨越時空。json這種是近幾年想出來的,不是標準,用著方便而已。

PHP伺服器端API原理及示例(介面開發)

但是現在的情況反過來了,我們要開發php伺服器端的api介面,也就是別人請求我們,我們驗證請求合法性,並查詢資料返回。本文簡單講講伺服器端驗證請求合法性的方法,和接收引數的方式。簡單的get請求如 請求這個 會返回一些資料,無論是誰用什麼程式語言請求都能得到資料。那麼在需要驗證合法性的情況下這樣顯然...

socket伺服器端

伺服器 include winsock2.h include string.h include stdio.h include time.h include stdarg.h include stdlib.h pragma comment lib,ws2 32 void errexit const ...

kerberos伺服器端

1.安裝tcl wget tar zvxf tcl8.5.12 src.tar.gz cd tcl8.5.12 cd unix configure make make install 3.解壓 tar xvf krb5 1.10.3 signed.tar tar zvxf krb5 1.10.3.t...