restful 規范(建議)


需求:開發cmdb,對用戶進行管理。

做前后端分離,后端寫api(URL),對用戶表進行增刪改查,應該寫四個URL(還要給文檔(返回值,返回,請求成功,干嘛,失敗,干嘛)),然后分別寫視圖函數。

http://www.cmdb.com/add_user/

{  

  code:666,

  data:[數據]

}

http://www.cmdb.com/update_user/

http://www.cmdb.com/delete_user/

http://www.cmdb.com/get_user/

 

把這四個URL給前端,Vue里面發axios用的是jquery

  $.ajax({

    

  })

 

 

 

訂單管理:

第一種:接口開發是用這種方式來實現

路由:

from app01 import views

urlpatterns = [
    url(r'^admin/', admin.site.urls),
    url(r'^get_order/', views.get_order),
    url(r'^update_order/', views.post_order),
    url(r'^add_order/', views.add_order),
    url(r'^delete_order/', views.add_order),
]

 

視圖:

from django.shortcuts import render,HttpResponse

# Create your views here.


def update_order(request):
    return HttpResponse('更新')

def add_order(request):
    return HttpResponse('添加')

def get_order(request):
    return HttpResponse('獲取')

def delete_order(request):
    return HttpResponse('刪除')

 

這個方式有個小問題就是前端記着的URL會越來越多越來越多,后端給前端提供的URL也會越來越多。對十張表進行增刪改查需要四十個URL。

 

所以漸漸地就出現了個潛規則就修訂了一個規范,如果按照這個規范做的時候會簡潔一些。

就出現了restful規范,是對上面的一些建議。

其中第一個建議就是:對於一條數據,就寫一個URL就行了。到后台怎么去區分增刪改查呢?根據method的不同來區分。

就寫一個URL

路由:

from app01 import views

urlpatterns = [
    url(r'^admin/', admin.site.urls),
    url(r'^order/', views.add_order),
]

如果執行這個order的時候,這個URL隱含了增刪改查。在后台做個區分,前端如果發GET請求就查,就獲取一個訂單。發POST就傳建一個訂單。發DEETE請求就刪除一個訂單。發PUT請求就更新一個訂單。

視圖:

from django.shortcuts import render,HttpResponse

def order(request):
    if request.method == 'GET':
        return HttpResponse('獲取')

    elif request.method == 'POST':
        return HttpResponse('添加')

    elif request.method == 'DELETE':
        return HttpResponse('刪除')
    
    elif request.method == 'PUT':
        return HttpResponse('更新')
    

 

 

 

也可以基於CBV來寫,基於cbv會更好,因為基於cbv,method判斷就不用寫了。只要寫上方法就可以了。

路由:

from app01 import views

urlpatterns = [
    url(r'^admin/', admin.site.urls),
    url(r'^order/', views.OrderView.as_view()),
]

 

視圖:

from django.shortcuts import render,HttpResponse

# Create your views here.

from django.views import View

from django.views.decorators.csrf import csrf_exempt
from django.utils.decorators import method_decorator

@method_decorator(csrf_exempt,name='dispatch')
class OrderView(View):

    def get(self,request,*args,**kwargs):
        return HttpResponse('獲取')

    def post(self,request,*args,**kwargs):
        return HttpResponse('添加')

    def delete(self,request,*args,**kwargs):
        return HttpResponse('刪除')

    def put(self,request,*args,**kwargs):
        return HttpResponse('更新')

 

restful 規范

10個規范:


1.與后台做交互,通常采用https協議,這樣安全.

2.域名 有兩種格式

子域名的方式:

https://www.baidu.com.
https://api.baidu.com 這就說明這是百度提供的這個接口,這種存在跨域問題(域名或者端口號不同)瀏覽器有同源策略,就會把這個請求回來的時候瀏覽器就給阻止了(同一個域名不會阻止,不同的域名就會阻止)。需要自己解決跨域問題。

URL方式:同一個域名,知識URL不同。

https://www.baidu.com.
https://www.baidu.com/api/  



3.版本 ,接口不能保證不改動
https://www.baidu.com/api/v1   第一版
https://www.baidu.com/api/v2  第二版

能加在URL上,也可以加在請求頭上。    跨域時,引發發送過多次數。

 

前綴:

https://www.baidu.com/api/v2

 

面向資源編程:本質就是把網絡上的任何東西都當做是一個資源,對這個資源可以進行增刪改查。一個資源應該是個名詞,所以一個URL后面跟一個名詞,這個名詞就代表這個東西,我要對這個東西進行增刪改查(get,delete,put,post...都是動作)對這個資源進行不同的動作進行不同的操作。

面向對象編程:

面向切面編程:


4.路徑上所有的東西都是資源,均使用名詞來表示。不用動詞get,delet。。。
https://www.library.com.api/v1/books
https://www.library.com.api/v1/book

5.method(請求的方式)來表示增刪查改,鏈接上看不出來只有在請求方式上能看出來增刪查改。
https://www.library.com.api/v1/books/ get請求,獲取所有書
https://www.library.com.api/v1/books/ post請求,新增一本書
https://www.library.com.api/v1/book/1 delete請求,刪除一本id為1的書
https://www.library.com.api/v1/book/1 get請求,獲取id為1的這本書
https://www.library.com.api/v1/book/1 put/patch請求,修改id為1的這本書  put代表全更新是全部更新

6.在URL上傳參的形式傳遞搜索條件過濾條件
https://www.library.com.api/v1/books?limit=10 只拿前十本書
https://www.library.com.api/v1/books?price=20 只拿價格為20元的書

7.狀態碼  ----->給客戶做提示    狀態碼跟code結合一起用
200 OK - [GET]:服務器成功返回用戶請求的數據,該操作是冪等的(Idempotent)。
201 CREATED - [POST/PUT/PATCH]:用戶新建或修改數據成功。
202 Accepted - [*]:表示一個請求已經進入后台排隊(異步任務)
204 NO CONTENT - [DELETE]:用戶刪除數據成功。
400 INVALID REQUEST - [POST/PUT/PATCH]:用戶發出的請求有錯誤,服務器沒有進行新建或修改數據的操作,該操作是冪等的。
401 Unauthorized - [*]:表示用戶沒有權限(令牌、用戶名、密碼錯誤)。
403 Forbidden - [*] 表示用戶得到授權(與401錯誤相對),但是訪問是被禁止的。
404 NOT FOUND - [*]:用戶發出的請求針對的是不存在的記錄,服務器沒有進行操作,該操作是冪等的。
406 Not Acceptable - [GET]:用戶請求的格式不可得(比如用戶請求JSON格式,但是只有XML格式)。
410 Gone -[GET]:用戶請求的資源被永久刪除,且不會再得到的。
422 Unprocesable entity - [POST/PUT/PATCH] 當創建一個對象時,發生一個驗證錯誤。
500 INTERNAL SERVER ERROR - [*]:服務器發生錯誤,用戶將無法判斷發出的請求是否成功。
等價於:{'status':100,}

class OrderView(View):

    def get(self,request,*args,**kwargs):
        response = {
            'code':100,
            'msg':'successful'
        }

        return HttpResponse(json.dumps(response),status=201)  #狀態碼也可以寫其他的    用code還是狀態碼   對狀態碼有要求的可以寫

 

8.錯誤處理,,返回錯誤信息給客戶,error當做key
{'status':101,'error':"不可以這樣"}

 


9.返回結果,針對不同操作,服務器向用戶返回的結果應該符合以下規范。

GET / order 獲取所有訂單      collection:返回資源對象的列表(數組)

GET /  order /1  獲取一個訂單的詳細               collection/resource:返回單個資源對象
POST /order     返回新生成的的訂單   collection:返回新生成的資源對象
PUT / order 修改全部部訂單            collection/resource:返回完整的資源對象
PATCH /order 修改局部訂單       collection/resource:返回完整的資源對象
DELETE /order     collection/resource:返回一個空文檔

10.返回結果中提供鏈接,連向其他API方法,使得用戶不查文檔,也知道下一步應該做什么。
返回結果中提供鏈接(獲取一本書)
{
  id:1
  name:xxx
  price:12
  publish:www.xxx.com.api/v1/publish/1

}

 

 

 

 

面試:談談你對restful api 規范

  他都有什么?談談你對他的認識?

  面試就是講故事!

  本質上就是一些規范,定義一些規范讓咱們寫api的時候更好作區分更容易讓我們的后台去做處並且讓前端更容易記住這些URL。就是在這個URL上體現api的操作。

  。

  。

  。

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM