這篇主要是針對(duì)於個(gè)人目前學(xué)習(xí)django rest framework的一些小小心得，在開(kāi)發(fā)django而言，想要撰寫(xiě)restful api，是有幾個(gè)套件可以選擇的

• rest framework
• tastypie

主要而言是這兩個(gè)，個(gè)人是學(xué)django rest framework，tastypie個(gè)人沒(méi)啥碰所以就不做啥比較了，當(dāng)然你也可以不屑使用上面這兩個(gè)，小弟有看過(guò)使用requests來(lái)實(shí)作api的 :)

大致上這篇會(huì)用下列的順序介紹

• core part
• serializer
• generic api
• url router
• some situation may bother you

core part

個(gè)人覺(jué)得這套主要核心整個(gè)圍繞在serializer上，其他的有class based views的相關(guān)api，api通常會(huì)跟permission和authentication有所關(guān)聯(lián)，最後如果想要用比較generic way的方式，就要用到viewset和router。

這邊rest framework的quick start個(gè)人覺(jué)得做了一個(gè)很簡(jiǎn)單上手的示範(fàn)，讓你先了解一些基本概念，serializer的基本使用方法，如果有看他source code，可以看到他的概念就是從django form，field那些過(guò)來(lái)的，所以會(huì)有很多類(lèi)似的東西，至於serializer比較深的東西，下一個(gè)段落再來(lái)多說(shuō)明。

quick start 後面也提到class based view的使用方式，不過(guò)他是從function based view帶到class based view，個(gè)人比較偏好class based view，可讀性更好，假如你一個(gè)function based view可接受很多http method，這樣裏面code就一定會(huì)參雜各種method的相對(duì)應(yīng)code，很可能你裏面就會(huì)有向下面這樣

1
2
3
4
5
6
7

def (request, *arg, **kwargs):
	if request.method == 'GET':
		pass
	elif request.method == 'POST':
		pass

沒(méi)有說(shuō)那種一定好一定壞，就看客官的個(gè)人喜好囉~~

再來(lái)request和response在restframework都有經(jīng)過(guò)額外的包裝(包裝django的response和request)這邊比較沒(méi)啥要注意的。反而是authentication和permission比較值得注意，也就是對(duì)於API進(jìn)行一些存取權(quán)限的控管。有個(gè)地方需要注意的是

1
2
3
4
5

permission_classes = (permissions.IsAuthenticatedOrReadOnly,
                      IsOwnerOrReadOnly,)

authentication_classes = (SessionAuthentication, BasicAuthentication)

permission是裡面所有的permission都過(guò)了，這個(gè)request才可以執(zhí)行，authentication是只要裏面有一個(gè)成功通過(guò)，那就可以執(zhí)行了。

不信請(qǐng)看，rest framework源碼片斷

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

for permission in self.get_permissions():
            if not permission.has_permission(request, self):
                self.permission_denied(
                    request, message=getattr(permission, 'message', None)
                )

# the process for checking authentication
for authenticator in self.authenticators:
		try:
			user_auth_tuple = authenticator.authenticate(self)
		except exceptions.APIException:
			self._not_authenticated()
			raise

		if user_auth_tuple is not None:
			self._authenticator = authenticator
			self.user, self.auth = user_auth_tuple
			return

最後的core part，就是viewset和router了，這部份就在url router那邊再多做說(shuō)明。

serializer

serizlier跟django的Form使用起來(lái)很像，但是這不代表它是繼承於django的form喔，有興趣的看源碼，用serializer的目的，個(gè)人是覺(jué)得把表單驗(yàn)證的邏輯(舉凡參數(shù)驗(yàn)證也可)從api view切開(kāi)，這樣也不會(huì)讓api裏面的程式碼過(guò)於複雜。

一般而言大多數(shù)情況應(yīng)該都是使用modelserializer，的確針對(duì)於CRUD方面確實(shí)方便，但是有時(shí)候就是會(huì)遇到當(dāng)你create這個(gè)model時(shí)，會(huì)有和model對(duì)不上的欄位，進(jìn)而造成錯(cuò)誤發(fā)生，或是很難使用，拿個(gè)最簡(jiǎn)單的例子，創(chuàng)造一個(gè)使用者，通常會(huì)需要一個(gè)email，password，password2，但是使用者model並不會(huì)有password2，畢竟那只是確認(rèn)使用者密碼是不是一致。

對(duì)於這種情形，我是另外寫(xiě)一個(gè)serializer專(zhuān)門(mén)為創(chuàng)造使用者，而且也不是用ModelSerializer，只是一般的serializer，那記得要define create的method，假如你是要用在generic viewset的create的這地方。

另外使用modelserializer會(huì)遇到的一種情況是，今天你想要客製化回傳的資料，比如今天你的user model裏面有一個(gè)欄位是mugshot(ImageField)，那個(gè)一般情況UserSerializer.data，那麼回傳格式通常會(huì)是希望是大概如下

1
2
3
4

{
	"email": "aa@test.com",
	"mugshot": "http:///media/.../"  # url 位址
}

但是往往天不從人願(yuàn)，預(yù)設(shè)可不是回傳url位址，像這種情況我目前知道的算比較OK的解法有兩種

第1種

就是使用SerializerMethodField，基本上就是建立一個(gè)readonly的field，使用方法文檔說(shuō)明了很清楚，這邊我就不多說(shuō)明~~

第2種

就是overwride serializer的to_representationmethod，這個(gè)我是看源碼去理解出來(lái)的邪門(mén)歪道？ 不過(guò)這邊也只是跟你講講也可以用這樣的方法 :p

再來(lái)就是文檔的地方也有說(shuō)，使用serializer時(shí)，帶入partial這個(gè)參數(shù)是可以直接partiali update或是其他的東東，這是一個(gè)不錯(cuò)用的東西~~

1

serializer = CommentSerializer(comment, data={'content': u'foo bar'}, partial=True)

最後其實(shí)剛剛上述的對(duì)於creation的用途另外寫(xiě)一個(gè)專(zhuān)用的serializer，你也可以不要這樣寫(xiě)，就全都寫(xiě)在同樣的serializer上，用上面的userserializer繼續(xù)舉例：

1
2
3
4
5
6
7
8
9

大專(zhuān)欄