RESTful規范(建議)
一、最原始的接口開發
這種方式雖然可以實現接口的開發，但是一個表的處理就需要4個url，當表單多的時候，需要寫大量的url，這樣不利於開發，並不是接口開發的最好方法
#url路由分配
urlpatterns = [
path('get_order/', views.get_order),
path('add_order/', views.add_order),
path('del_order/', views.del_order),
path('update_order/', views.update_order)
]
# 視圖函數處理
def get_order(request):
return HttpResponse(' ')
def add_order(request):
return HttpResponse(' ')
def del_order(request):
return HttpResponse(' ')
def update_order(request):
return HttpResponse(' ')
二、優化接口開發(FBV)
根據request中method的不同，來執行對應的方法，返回值給前端，這一種開發優化了上一種開發方式
# 把原來的四條合並為一條
urlpatterbs = [
path('order/', views.order),
]
# 視圖函數中通過判斷request方法來進行對應的處理
def order(request):
if request.method == 'GET':
return HttpResponse("獲取一條或者多條訂單")
elif request.method == 'POST':
return HttpResponse("增加一條訂單")
elif request.method == 'PUT':
return HttpResponse("更新一條訂單")
elif request.method == 'DELETE':
return HttpResponse("刪除一條訂單")
三、進一步優化，基於CBV模式來開發(CBV)
在FBV基礎上進一步優化，CBV開發模式下繼承了FBV中的路由簡化，同時也改進了視圖函數，開發人員不需要再對request方法進行判斷，直接可以開發。
#url中的路由分配， 使用CBV模式的時候由於需要調用dispatch方法，必須在url中的視圖后添加as_view()方法
urlpatterns = [
path('order1/', views.Order.as_view()),
]
# 基於CBV模式進行接口的開發
from django.views import View
from django.utils.decorators import method_decorator
@method_decorator(csrf_exempt, name='dispatch')
class Order(View):
def get(self, request, *args, **kwargs):
return HttpResponse("獲取一條或者多條訂單")
def post(self, request, *args, **kwargs):
return HttpResponse("增加一條訂單")
def put(self, request, *args, **kwargs):
return HttpResponse("更新一條訂單")
def delete(self, request, *args, **kwargs):
return HttpResponse("刪除一條訂單")
四、RESTful規范
RESTful規范是一種網絡架構風格，它結構清晰、符合標准、易於理解、擴展方便，所以正得到越來越多網站的采用。但是是否遵循該規范以及如何遵循該規范需要根據具體的業務需求來決定。深入理解RESTful規范
- RESTful API設計
-
HTTPs規范。API與用戶通信協議，總是使用HTTPs協議，這個協議比HTTP更加安全
-
域名規范：
- 方式一： 把www.換成api. 例如：正常的子域名是https://www.baidu.com，如果使用api接口，可以把子域名設置成https://api.baidu.com進行區分。但是需要注意的是，這種方式需要開發者自己來解決跨域請求的問題。
- 方式二：同一個域名，在url設置上進行區分，在域名后添加api，例如：正常的url是https://www.baidu.com，API接口的url可以設置成https://www.baidu.com/api/，這種設置由於域名是同一個域名，不存在跨域請求的問題，使用更加的方便。
-
版本規范。程序的開發過程中會不斷的升級，每一次升級都是一個版本，所以開發者需要給程序添加版本用於區分。添加的方式有兩種：
- 方式一：把版本號添加到url后，例如設置https://www.baidu.com/api/v1/，v1既是開發的版本號。
- 方式二：把版本好添加到請求頭上
一般情況下使用的是第一種方式
-
路徑規范。面向資源編程：把網絡上的任何內容都看作是資源，對資源進行增、刪、改、查操作。基於面向資源，API接口url設置上盡量使用名詞來設置，可以寫復數形式。例如：設置https://www.baidu.com/api/v1/source/，注意：source為名詞，如果設置成get_source則是動詞形式的。
-
method規范。
- GET: 從服務器上獲取一項或多項資源
- PUT: 在服務器上更新資源(客戶端提供改變后的完整資源)
- PATCH: 在服務器上更新資源(客戶端提供改變的屬性)
- DELETE: 從服務器上刪除資源
- POST: 在服務器上新建一個資源
-
過濾規范。通過在url上傳參的形式傳遞搜索條件，例如：設置https://www.baidu.com/api/v1/source/?name=李明&age=23
-
狀態碼規范。常用的狀態碼如下：
- 200 OK 服務器返回用戶請求的數據，該操作是冪等的
- 201 CREATED 新建或者修改數據成功
- 204 NOT CONTENT 刪除數據成功
- 400 BAD REQUEST 用戶發出的請求有問題，該操作是冪等的
- 401 Unauthoried 表示用戶沒有認證，無法進行操作
- 403 Forbidden 用戶訪問是被禁止的
- 422 Unprocesable Entity 當創建一個對象時，發生一個驗證錯誤
- 500 INTERNAL SERVER ERROR 服務器內部錯誤，用戶將無法判斷發出的請求是否成功
- 503 Service Unavailable 服務不可用狀態，多半是因為服務器問題，例如CPU占用率大，等等
Note
在實際的項目開發中，可能會出現很多的情況，雖然現有的status_code已經有很多，但並不能包括所有的情況，所以，需要把status_code與code相結合來使用，code由開發者自己定義值和所代表的情況，當然status_code和code都可單獨使用。 -
錯誤處理規范。狀態碼為4xx時需要返回錯誤信息提示，默認error為返回的字典中的key，當然也可以自己定義。例如：{ error: 'Invalid API key' }
-
返回結果規范。針對不同的操作返回不同的結果。這些結果應該符合restful規范：
- GET/collection: 返回資源對象的列表(數組)
- GET/collection/resource: 返回單個資源對西那個
- POST/collection: 返回新生成的資源對象
- PUT/collection/resource: 返回更新后的完整的資源對象
- PATCH/collection/resource: 返回更新后的完整資源對象
- DELETE/collection/resource: 刪除后返回一個空文檔
Note
resource一般指的是數據中的pk值 -
Hypermedia API規范。RESTful API最好做到Hypermedia，即返回的結果中提供鏈接，連向其他API的方法，使得用戶不查文檔也知道下一步做什么。例如：
{ "link": { "rel": "collection https://www.example.com/zoos", "href": "https://api.example.com/zoos", "title": "List of zoos", "type": "application/vnd.yourformat+json" } }
-