From 20cc573b98aab49fe91e278c9ed4bf0d71107839 Mon Sep 17 00:00:00 2001 From: Tom Christie Date: Fri, 16 Nov 2018 15:41:58 +0000 Subject: [PATCH] Deployed 2084555f with MkDocs version: 0.16.3 --- api-guide/serializers/index.html | 2 +- img/premium/lightson-readme.png | Bin 10618 -> 16520 bytes index.html | 2 +- mkdocs/search_index.json | 4 +- sitemap.xml | 128 +++++++++++++++---------------- 5 files changed, 68 insertions(+), 68 deletions(-) diff --git a/api-guide/serializers/index.html b/api-guide/serializers/index.html index b82150a54..9c6448ef8 100644 --- a/api-guide/serializers/index.html +++ b/api-guide/serializers/index.html @@ -802,7 +802,7 @@ class EventSerializer(serializers.Serializer): def validate(self, data): """ - Check that the start is before the stop. + Check that start is before finish. """ if data['start'] > data['finish']: raise serializers.ValidationError("finish must occur after start") diff --git a/img/premium/lightson-readme.png b/img/premium/lightson-readme.png index 5a1fad4217c29c16eb8b944364570a690d831d02..3c8c6c62a28da0c159b72c58f91078ee8eee6da4 100644 GIT binary patch literal 16520 zcmeHubyQriTub?&`g}swd*3vMegnJ0u7Q2vm7FDOCsvNNRBV5djYTi_jtf4*`Kx zZY3%CQC?D#{G+3txfRe10zxh#B@O2IU%&|wiHM8Q@Iw~5z@9}m9!9Z#pN zce_vHKhPmAeHuTeqm4kuQw(B-Jb7>$Z*LJcTR=dulS5$nFA~>IQZX|lkZ03=%RyvdzLp@>ZZOX=;N zsb>DeBoo`>VO&wsv>Csr0AgbZ*hmixG41tpVsNjJ++&bCm<3j^0|H4TJmPu#$)5x zvO<83{K{tV!DIV~Nw)~b{_krb8^Z&>7pl*Ay>qX`*bBdBXk!kAcl?q_zzjLy4cWUq z9f{a=O_==>wZ59iuZuwfJ}k%t2C4D04ZN+b+UpXfg~4332Lh=n)9`b1^uKfD|LtMTARnibY7* zAjgleX#N8BFvQT68z=`bX=G)VweehQ$holae7t8u8QA)rVR{quVK=S}+7EwRoF&}=CoExq^q@#;I9c2bA z52DdOqXwQBLAFO>6Ne9bJmhM_#-30Qnk-azL;3!lH$JJqVGlOFKjqg0dYfdz$cRgc zkZ)U`hUhWBkd#BHN0y7f|GNB1xOAlya+YbpR`x)i9fWSEHvI$wfqBw30xsz8@PB4nRFTRQA|ra?TVoSZWbO z5oSMWx1_gBwgj;v3MCz>Stu{$iR8=*3kpXH#iuRmpq7G=~RjzfxZ$d+~=q(G#tn8no0 z;mYB_!QFvjGIz32a$<5L<9mix)yLBB#m80Ig?jnFzI$svL?KD`$|%w3_;w1d z{)|4CdcD+D_Fg)k`iOc|wfZ*~gWs@{37g$=7RekfgxkwU%dg8=CtpqsPUJ}>bLexF z1jYnZoFiHkS4~&3R#{gagjw2++TVM|c%t7RJ}Ua;zLLI>zQnt4 z4$OpoF*oHxuLsu4)QdZ{c*H-@UTIt{;CbR*;0dyLGI!`MYZvR1g1k+OjBt$_hRRou zDjOo+547|=#-jH1FPOJ0WsMQ(s;yA3yfogOl)84i>K?ZocPt4mMjdAz4-j7yV-Yiw zJZ5m46V!)$EMaaR95%0AL~mQrd6h7im?--RWbv2q^YX>9a_gmo&Nq4}@Ja9+6&gnT znR?%M-&ia_^4jn=>c*^ax#_!Ac~w4zht+Oyl{Jzd-j+Fsg_ z+q`^myuW!5`{X_z-51~UJjOmPJyhQQJ|DP;e>}TBv#_e+`|dgK?l0N3?0+ieXe4Fi zu~AQ+ME>cc7dtUAMjO+;L%44^dEtAU;5rGn5D`Q!lo1rcc7#@X;HSQC`l?;MFcu{ ze2r@-wpOFU(iT~U3?1#tHmB7Us+raFQ#+229hY{GcL%W95jhZ15e=8V9>2SlqGYP& zbjaTBTk7=~a@kL{A4t?oj7*YA)K82`l2y}FbuEg%_~l;Irs>V*%m1cS?)OFgXaF<` zlC)AgA<*^5+XdJHb^@!k|GR@*xrb@-HDs(})b7P(SqIauSQ zZ%q9l&Y6Cash{v-Wp+KhU9qEysG&c>F|?G)mH0dBY2?fGm+_;j_siBiRfKxKYa2aD zK&%e>3!bYt9>2qQ?`=v~VrkZ~)Yj6uZwOa&zM-qg8}`jyPHn4nYkj$W5v&n}5j;I{ zUeVTMHq6!)0x`L3Dj*gV=I^|m?zUDZFQ;mpP@E&GyLq^dSNbFiJXcA)JGmk6f6HaWeZ`WGu(YsdbLZbjxor)pLv=1 zy)@#wnuc%Y0vWS$4{G>cjOq z|0;a`v|Scm#z3L_GnWwdV|e$_5Ja0W3|fs zS=rEhS(#mfTrE1}!9BZRmWl%QgK~HP1SE<5g%0Mu<_pP;0&KGSa%3I&vG$Vh{%FW77DS|{!PA=qVYA&EECG$@> z_)3`4(%IQwfQ`+~&5hNKi`CB2f{lZppP!ALlZ}&;1p+rNXE zxm*1&us=QjE6mj7zpb)&aRmNllc@=t8PLqe%+}cnjN|yX;=sQBZ{Yu>q&vX=AHx1} z;y-K?`lGpks+p4=(B+Q{)NQStML322GU#8)|KpK=pd{^V>>bUVoWL*<_J2bDPWxAW zt^W}t!uww`{!aW?fQq9P*iyhBy+kjgeqxtjsCq^!UW z{mTkYez02qw&!1wl6F8lM>TtZiP;~`{(}6C^sn51$R(&8Hd=pV%b1H%#M#ZmmJAwLCDe-anPkYY#1f=MW(gi55|AB7s()8F&+J-MB3 zIy=nB&COV8zxFzH%F8ILsyf%W(JfKVDJRA8q;g_e3h_(=sp3LOaTI;SQ)~JoEKPb^z}h~Ef~m9; zICN6tT+gGj^B!b2P+C5=*Y&{^peGnHfII1d88j&YIGQcnoRTF&b=q@Qu_EFDYPqjJ zt>J6vIrP;We2WT|#?z)AzDvLZzwd@O??Z`uFaBEHeyijDd@;~V zWXF!s#8w~^gJfOx!(7WG=6%oo#Wu8A4u^?MI;Yu(fx=Hgy+0Fz zda-)pLi$3PP1DhlCdM;~3^HdB+}cFwgoG=!grD}WJL40OQIUQ#3sD!Uh47m%U)`~d zI4M6G%NQf0lj5uio6DVRSyTxR^LEa+<(X2iaJ!2kSgrfqp|038+yX$!FPEyOVy@j zZaeP*{0zqg+@EiLa^$iYN2%_7^>jZhO6$Q^5yJF+`E3|x_;RGV*@th)oVfbzHLq*e zejY^jOimf|5OCG;%VB^75JuuE2jAN1A?J7BOBQODra#}_F+`gcY?0?P-;M`g)pAt+ zDeKdjEt1VmTIVwjvHL~>;SiT$pv=hwO(}}f41M{3 zdFb4@ zxKs3^dfqJ3-n>k+fO}f1W#;$(dcGZD@;FvPo^qJFU#2pFurJI-r76Nhn2`Gt%K<3u zm79r4n15bi`Y~-qH|>vs^=|rS1oo;U%a5JJQ^`FUTdYAj1O|@F64=Ci6IV)XT15o# zl(Jtm&$8*6R$wEUY!jl$<1p!$av&(;UA8Q!d3${dD~J_f)boAV1O$`pHd-ivNwOf(?x`wjD~enJE@f~E8M(l#R; zntzHFg%UI}AaYw-SRj}MpXA+b1`nn8+tA@=lZ>*@KITcvC{Arn9Y-F6kx#IrRwE$KEHo_3 zFvmt}aT&%`@7-K4RiRa>oG`{)*^#4+)4sW8$5Ml9WcM|db$K@e_^G|4Q+8)#+3yd+Q zzg#<;)bK$wU?T;yy)TC_t4=VeGbweR!1D$V^Kss8n?+@!}%gO~)5Oy{{4L|p)q7kyCCHrFvf zBNV14zHUsw=D3#Tlk^*?F9Tid+f zj*I*JLOZqGa=muf!JF-M`Xhj0Baks3F4Kf9_)wix+q$x$r*Xx0g`08NjZ_yW3ft?X zL30LF$6Cc}D|bIs$g$aO0w=qytkKrC$u%}!|FYHFb663LroaJzT$i820ysRim>H%K znEctI_x)k$rdV@K#kc#VZd~AZaJA2gHKdn369B3A1F6~%p$iX)Si#fgL4*;c$v|2a zkq1-0!@?v=la8i$jkn9zVW_;nCL8vD`MtetW?EMv&XlN}Y1+u41v$;n3U)vWZti8- zk>VM8U+|Sq&`CMp%xQ*ozMR-im6J3!RW_{&)REmp@SVZi+o!aGc)Z)g zwb(MS8q?`$W{5llpuC3>bs41k$_dj9fVq~ArEXYyqw^xw471I3=IM~)$bC{2I{HE; z%i*zw`SNU4>!F*fDrRC3=?vE~mNwI;3l_!B*ZTp{P+3wBYR@imY7KXHt@IB+nd}^% zclK{r?8shU&iul#mH8+L+r+#}I>N|&-OaVN)k7wQv&Kc=9wzK3#o?tDE;0~7&0XJm z=tLieMzu8cUDQpgUn?w2Nf@hUs|07DZg8afO{I1|h z<#&}++7>eI& z-ZD7#jP$cJ-%t^>;nyEdn-|0SxI83m+VF&2;xHrFl+c8R8Fun9{mL^@XSQ342y<-= z7k-hgVrK;U+$EoTrnby0f71_VlK2pC-`Ld7;(ZZi7){Kqmi8@AQFGGQw(UaZ%n>KF z6L}e1=7Q|yKsE!NuHaHb*9P~zFL6f}VhmaKv&y8Z@Dm=4%d%AoEL_s{2hyD(oXa2k zxmStD_;6p38$e4&qwDmv8GMNja)r1r%g>RwUiM$y`!hzA8qLawoc2Ox%|}uFe9T<= zW}ZW}%oLoUIvvWXtAogV)mEaej;^soY=Ua{9BYol?YFR3=XxSjm4cHc&;|yW{m7m( zz~S<}*fd%36uiu%y4wyI{2H?M-tRst=5-TzX*#k)fQ_>i+L?hO+?0w;mGSBeto&V^ zWsAhS?(IZ8d&U(v0?o@}UOqB!?wdl5z2FH?x=_^NC6+#8t3B?j0Vf)p-QxUmzG9C_zE=Z=q*k)i$Y+S zf^s%K7S+DYdwZtSp%`h&MYGTeJo&b;MVMNDX*$Pn7L=AEv$Sa`7$gl3lV+ZL=TwjpbW$V9ntd)-L_}J`<9oHi~4meLcc_EOyIIjpylaLTzr z;%1r2s12(rAuk(ker+r{_0u6a1mtEKsrCAd&26ME>;;$kAbsQ>xIM$BpkW6`_=p;T zV9fqa6d)5dOB%M5M*az5LuhC|VUg~Lkh zHod+?yUtn2C0rAYb;quf>RZqAB=Pyav#>~w%1Xoc(EGYo6iTsRsiy6;<+ltSV@+Y) zh_r!X#_3mBK8I$RY5Mvg~7UQykiD>z(xYL(U{7E?LJCeW3>Cvg=5SB!fh)I+E{H8-e|C`R ztWD^ju0xZ%{qQLrtFm9HG@seZv_FAn(fKjFXkGIe8Im;NLDf`>FNJtanzR)Pg^-hU=LBB%>;{G1u+1Jee8eC7~ zwUQXv@qP(Z5H{9XwgPoQZ2hz|&r>k>Euzd^s!9X@cKYiLYGHUhmL*q@;|_5C6VCDU z{{6B^oUrSwzT(9qO)d>FATV?X(RB7OQS`8}zzh&#+&ky(nIr zW%xaMY3j2XRRPp~#^o}I`@lzl6=t0@dg&cWGJP8Ye@w8Qtuw}H-pp@RH02sdT>^Ja zQ}{J?0NPxvrC!!x7WgQ9RC~CIA{Z2*-lKKj0^&FpW0I#VY=%9?j@bhr1VL5|5Tc@s zO^UA5)N_yq0kfOuULv>Gcsn1I?%oBs6D>cm5r`!vHzVqHCo$OS!Lm1_RMpk^_z)x#2I1^DQ6%A%?X9SPdHa? z{kWvD^eh$ia#4os{ZU2r9_Rgbfm3P@6{sku%~B-Mr_nQC+X&e_?R9#u+PNobhO(2i z(f=nB!VEiio((Xv-}X)22DpJ zy*?h>pVrUxc8|nG@+{HbkelmU@@6eQkdhJb&ZEudVcXWISC&w+uyw<;za5j6*v1J#g1BBP9-i3T3m=jfav75J#{;9aT$U|vG267=7ic$QoZ3UH1NZtaWW z>@v3cWlou?d4u1}s;JC1*&@HlS>lU2VDH*v@1}B^!I6X)V(qCR>!D_6^>=a#y2bl# z<*v~2x}zlZMp%w)8xe3uM5~a&Mb-B?)_o2)icor2AWP@uOW1dP8+5K^rGzjfKQffn zlBI;E@8h+lv!;27ERqlpx{IGZmjBwW|^gZ3o>Di#aMLA*OcMZHuBAW+A4y@8{-LX8OI2_Zbu3 zv~_nLb{s=3Y-sxsO)7qmGn=QaXR$#@err}1WbgRinD7)a%~H*9 z5J@}IkjTZk40gA@_wVGTOiiX~9O@dlXsdDC@@v7)iEc$G&|7LR9sZ!3<&KYz>}YX*`hl91MI=vgbH z7IL|&Ek1#U87riodii7{;1kM7j^0k1*4OqG_m!{AM&LV?a%)m(&H_w?O26|t%znV4 zn+`d4H-U$iqw9&nTKooiJ0x^JW+1-IH9@Xch~nPYd6jb(t+8Q=Js9!0Q91UBW`jGP zsgY@^>R}F;;YY~j$!2BuZZq4T&W4S+TB>Cg1kPTZPDwLnw}8*#OtkE&%!hk4xYIKdTvsVMXLJC!m&L_`XVG*bnZP9(6-*3@8yo`~R&ZMoT##87 zS8xdN$2edBLvwp7euCSU@Q|3Qf|d+b;H0pyG#IMpp3)3%pOBMFe1T`_`;!tbK|mSY z)A`ax$`$KumWLT;;h?$$&aW24lxFk(9P&NpGTwim1&GR4nn7Z?<*yC19(%tKed}}) z%ekh~-@#~L@v|(TO*y<>0|<5E+==Vrd)K;7(*C7&P(JGOg&xt2gRa+4A z54+K*G~Q@o8(_!oM{hf9))H1nMWAN^o7Y@df-6u1Z_8%`nhc@s_juHRK^J)P(bYGD zHkYldN!k+`Jw$f_1st-GHGZ|>K+u#7pbuBm*^b8NR%#8LwY2@Qn#BpVpkrP6>m_hO zqgFdh*jx}$WOy>nBEZw1@2m!opre+t7yH#`q(V%&8~He$kp4jcWn>w zQu2d<<9)~LO*L;c{oZ<>V#T1_%E#pz)FM>Ds8T?dU>07NnC-{V?O4Go0FedJyno0D z;LP57af(XmYQ$*@?YrG#ZmcoD<9c2GW7+it7r-oSC^*e3gFvl(r?{bAg#16v7w zSt+c|g9hu)qFt|Mm3tlO;?Mhh`{qIg@<5@z@@Fn>yY`!JWlkEzYiOgOW$a=vMP4C5 z=GX;;bco0R5ikqU!X4kERgs>}6EXecklZ|*z;p@jM`?z3Xk{f{jts1bYE(s zcaeKGt1A~ARCq7;I9=e!x+*91n_UPYl^U{(4^ApI(wAS#DSMbw+@F-{1(H~I_mYPh z5%@?P2PptgCrxCNTcD%39Gqf08Jl-Df41V@N~rMW7pGik9NXm8B(94TYC#VNvZC*- zx?k3@wp6+yux?qNPMFN?~&*+wa8LbH)<{8U;dg;dBYZaI4>cq4Y6 z6rVCiL6*!xIO!u-ejBGWU)}@9A&V)-gj!=R23C&w@5(0ED~ptkaH?1YaPCg!8!qP7 zC7hYuCv;@$7rI_{0rV8DCMs!`6G!0F>feT1km z(WrQ>_G^TQIeyX_a|xnL#w&;I{u?SkWw;QG>7GbT*%>_j2di7O4rc>J2JoI{1*~zk z!`pmQ2W~rvlNJ^r``g`&Y&-PEArF5+9CW^#7fGz@ED|8#CP`~r>dZvN9+Mt=2q=y zX;^n9s5VfkqE#0=**l8OwthxT5y^dwi;C?(UtY+kq3dGb7Yy}Fv{-WHvbXO{zEbw!&9Ul_Z6}Q@P&{$m6rW^@ zF;Gy1#A@yDJMnota-U7#kLc#y^fbqXH7wz9Ww>4n@}z^8-$fs2Ry6?7sm%tCZoH5k zcg_21%u7OU$UAYJaIhXuJY4j*4rffc-`Nl&QCBU}HsY0CDicN6_q*?2ce{utKZkW1 zg>M&43YwI6*&9U(ys(L1?bcg?Ko!eF#x>zN!Sw)4{HYz`_&zgXx?}>q#SWd0zYJY5xO^I7vJ7@1LXCjFe9^-3=*LDGY3 zZbGH>Lqc>HW`goET~&7P`sq7xlD;u7H4v}o3!bh8hDMK2Wmco{hzcf0^~IonZbzCp zF6B2B1HYG>PlieZfXDG+;)?uLtVhe1JXH&gZ`xZHVt2tO0#<6__|@73CqXjl(m=}y zx?Fc-ZY^Ggk|gVwyftOjEH}1tsu?x``T0v0Cf$3VbM&iDaIt!dlp>X6?EIJP+=Lpn zK+A&mk2JKLY=Is5IKFrSH6gq4wJ$}b>ZHFWn6m4Gt*DsdkfA6z%8L;rJOR*wHSQlL zrGzYG;gHwJN08{Kb8rwMXnY@G0$q17n{6~1W;;*}v@5zV@;`Jmm$=g+3NR5fo!mPUJ@NfB6blyGAo*Nl>S(g@iiB-(*5X^8iGz@be=j`?>{1V&^@jK^VHO7D5V z@Z|uYCZa*1csf`79cp9%a%VBfpY5IEvyr2pPVZK3MRkY3vVCSp=bYW+2+s;|TgJr6 zuB|(5f|-mg94DqzwhL!T-Pn|gM3S( z2FZlzGu4DmcGaSFu&fPfvDpoDSG(B)-^+b{1|G~%AG!>&=mcG+u24_Oc7d=5IzYf+ zY8@GC^XpglAXGI7ZbLXEnP-rg93K~@V(Vn%G!(_xfcVrVqX6?hBTcEA5qER~7y0UY zW0f9Qau&rEb_JBe#!*Tr7~k1XvapTsJr+wwGWK~3`<>)FZ(rr9CY-Y9s=xCI*HU<7 z)FRp6Z-&V-@=En$2~*LBcAGP4WUBR6NqSdM9Vk!!BSX zj!ZxIXn9Ua98 zjU;%O)FT^=@0gfTT@pJH6 zJP^%sEkP#UiPNtQCP(+Wy&EQCITXu#`nCV-MemS%YyB8~Sck&Y6O&DP;9})PG0D93 zPLo081dhYK=QAp^HirVz9d&yR1uZwW$_Nc=IE%24`Nysb5!wdR$I1?q71N)0rW3+< z(ZxUv^XG|Kte9c!;=)FCTD6Lc(;=jwd;5$Z8-d8b_90m=z|~|s>ux%xYG=Nib2(9x z>aO=oOtaxX{_mN_i3=fT&h{sU9~OYi-T?;?pQnz{B=<9a^HoIERfM0s*U z5%JnDlc3(v2eaLAw*I2Iy=A^LKHn&n)?fOEL&-7f5HhTbA}+i%3_)>;L!7Vz37zvVt|Rzia+Gj;YYJ&e2rVYi=&bTNSy z#4ee2+WTM9Pgn&O%5kd{HOEBujS(dQrAsioKJ+&UKQAX7QtLjq#Zqep!Ub zc$m=E0UvY9)fE{JUG}+K)lCiH+{>uLoCvRW808pfe!#Rmv<=LX#!0(fh(nt&gTGQ6qD#l*r5TV1*j zn}GLav{bN?G{+*B5t5MuDvX-dO1dxtpMTjjt$y2Pan~Xr_|BPb{w}5^8QX-?V2imL zZ#7eFNuKL>=S<6PyC{=iPb&*>x9br5;?k^eA7Gox>l4!5)tblN_N!LBfhrz$yf$81 zKp!DFBwoXo#=#eZlC4Z^+6rL!2tJcRDm(V9xSsZ$(}Bp$mxg%4Ovv^cYuyDtgO)a; z$(G^j?bn(&#NG1JPA79>N&$%t&&N%|BfF*6!-3@=4jDi0e-W!3Jw<^3VoNm2ClE-* z`q4*Qz4v}_+(7`nLk0tfQLsZgx-EKAaY85NddSmrokFXa4#O!ChHx&jgQRz)M4KQJ zVccgUiy0c7o=(J7_Z->;!}u%ZNm8!_9J()4iE4DQkUxR8hgM?GY_JvXit;jM^yF*? zY@+E8OXNqgAR`07N0TWSzcSFR3dxMw?X+1}fgg2A&aaWrQ(5Dx7T!q*t;zfu@HgLl z@4qxqsy{;5bRm(x)agg8#P7G@bC%*q=w$kMeTw7!R3{;ZkQ^zt@K8{q)~Nbbbq{>a zY>#lA7+*-kV!tX5iwE@sV`J%b=xS9#;;2O+4Vh6I3rfN$KstY4<^&dx5LXWYA%Gdi zvlw`-Dmh#p-2=|6VL-7$QBvdM!6HFYe1rq%+c-aJ=7I-q2B+clv~cLb89735b68B@ z1I)2ONiN|C_>>QZnSm2;jLv{Z`jg)m7d7c6W7!tEtN2Vm-k^LPEk-keAj#LPDlP zl&=98h+jaH5GLXe*;zwQ5~*_d={Dj4=pe7_jD&KNX#KGb2?#}N1oZa5Zl7mZ7 zP>_R@n}eI14Z*?Y>}lr$^OzoCBD{I@W357>VL`(5)V>z<8yBx87q<`>mk{@J5sts{{L8{W&{9t3P#1eA zO?!JAh#Jhp+{X6zBj`ChKReH#*uQf81^n9%p%+dtbA*F`yAi@A!tsC5{?0FDZ|mS> z?(F=VpYtF5f2IAMU&Gwl-p2K}cr81a3xxY0kiU`tj?(>CJ%sIFfd@pWe~+Z@fa)?3Wqq|%ggHeeG>^6hY+N$6KGgY z$n;0R-zbwMUJ)XL;T&jBCAo*G*RM*!N>XTHenS8_+-3^0tBU3nf&^r;#DY5hhxi|d z{0|xoW-{`1HW*2+j3}fac)xHq2~D)qqj&{>HZ`6yd9;%lq@T7et6vKTJz`Wtcw@}s zI8NzMq(Mf2L_w2UY28n7<>WX|#K<=WqR`PPJsNsL@$XYx4Qj~+4nS=D*U z6wnlrk%=^ztisLdP?AC7lC{!fXp#bw zb!7i%2~AIwq&e09O0SgMx6%`d{*Wc)8qZcgBbm-`pS=lwtzPfCJJmnm=xqM8#j|$u z)oX>`7|O!h+FFSn!&awY8=V&UQc`w!1m0`;_4>K+)CJKG5<5vfD!ajOw|Pf7+aF?g zzh3Ttq9gM;D>Lf1u4*k(b~9Pr%CDsD;UIa+XEOe%RNZaKK_V&-#X1=r5i=VrYlvzL<_F?-& zTVw*qhx2Nc3_fntuTitkFEP&~<%_W9;8%WON7XMJSU02k1XUpgpQAwPpduwF z$D!S-fl^^v#WPFiU;U-l1s2QT(DH0|-!kTb!jsh1Lfdxdf^yhPZy{7|_SRn-p65R- zo#!HoahXEmb39gn+Y`kvSh=w*8ccey9zVB;x;e@>m*9%*sD^gWlNvpGjDFZ;H3rt^ z*vxc}d3Sr<+xabgq-?r8S;q2S@0I>r34zBYPL-v}t_h3-d8;w;yj3Ny7fQ`~f^xCF zCRF%I5raZ)4QG>G>l#P;;d)9k;#u-4+Erm!HZE8EJ_$g zuN?X{#Z^?I^q)hNPS}n;nxsv(h+9>eOpmIXlD^I&nNQ;E*nK+EA7MZZ z=j$!Q1V!{u?QY`R9hnlvOQPGio+azMFStgqxCYMF+wR7^U(Q{G6=%&y za$1O8E(N;MG7sOMH?;RN6=%k8%g3(N%Le3yJ*vQ6z{Zn|P^8w9$JuKut{|1=hPxEjw0l|Lghx(@u+8?)SGGjR^Ko>m+h&;qL} zJyV>T_bJmn*ogWf*v@M9C5*7rmYBB7lMvB7V)vh(#o&*2YBNVXVHheaoTl63g-Ylb zjeE6w=^L&}^B%*TD~}n9v)uGL*AreqbVKl|**PtC%{l|n4@9^ZTzxOEtJ>gaFCZKE z8dTbQ4ecKVHt1kK)|X}*7yw4LAmbUarIbKQJ!q*H`4i;kwCD%4=}qtmaU%-W5l@r~={@po0; z*ml}KOF!8-t(1UO-EFQ!^Vc(uFJP~gC#ikG)<1ou^!Dm}B_IqaMJgE#v10e1pL+iq zW2jZi!UQrQEh}-fJ_3|@y`9pv433WzJGX6E*cg^N2}O?`Q&gM_25$VA8Oe|xoJX>N9g_0Kz{Wox}+_cg|~rc&5IruY7cd5bB@mreEVsMBfQvDX$SOyJFQ zC1pPYO1=rZ@1fT+$2FWrYJMFocDMZ^vLC`dRBD-x6FqUAPLbc=mm;;B-CDR4DX2_O9`qQ3JT_ z&uWdj;t>y0cH_T9of6=vQ_vOL7qoRFx!I#-!y9$qbOp}cUgI#8*_5{JMQv309K+5& zq2;ctM&hv1BpIVi&WQUntB^u%Xs*pbq+Yj=x?U$>1Xdhy~P zsbU3I0G8Dp)osK5W=kFZC*NPbP>_+4iD!-eN>6jO^rbIFRqxXqdY#P2k8m92TFEsU?h)(4VP${B^HuUl+r#EV$OWc74v3z$a(}AgwL0fyxn6~;HpBS4 z_O%LHj=BNVvmnh@hc+^{NwJViu5JVK7dLx#BWP|fh*^ju*yx&VAZuL!pmX%ID+wgp zgw&bPq#Fe^TG+#7uh`nJi5Dr@94(_+JZW^I$>CcY1WCO1$pgbL$0Wq4KUj=)(e>a& zM>ZX{oDL5NfanNbN&$iWq3?9VV$If_ug{>DSI6Qc@Wr* zjd6piCz^_xEX~OxcF^=W!fn{b8rSiAx$bUE2z_INnB8PR#83)gD-Ze3@0@9|jV9aiqt5ahp77rL$Z_N4RNkM3N+~lJ(}Gr!SrV$W zCRcbqcQ+UASzE2gUny4Z@*<)RsP_~d3(C!%OLPmV8oRA@cEQmjyG8Bgt=^u!sO-xNwE-_dAMZLx}Sv1ZuR zhUrRIE5z_*eR>#^}O;N|?zl-p2=$26p_hqk=y=E+{Y*u^~s+^5e^!oV7 z><6dq8_v(?EhY^M1+3kT68!THQh~O9YOnhb@#N)^rSs%hHZttpw6`(iNiuzwlrQj| z-Tl$T9z3tZ?a=w_K}g->R{c9Zjy+te?4^Eox5_oAtw^s$U_3%Fn{CYbZITK{k;fD;XaX87&1?0A!K8bTB?rrv|O^GIFwzh1cuO^l_YBxDStvw1dJQ+g0xFRB< zdbQV(!!zfZ(uEx&btF=@mmgwJoJMIYj}^8ggV;aJ(?QUir>t?^wN=6$4j$B|z0Z4|b7D=Yg#}vF%{_V0}naKV%uewz7W4i3@2tB7)V-l3)KAFa$D*1Ob6zjPX6^e$Pe8T`;0U)chpG=-<0RAKy*TU~%`-N|O`~6uJbj*W| z1_gBSL7_xl*MtD|zJ5Yp=0?T5jw_)6#?gywlbS2M!eG8Xrsl(`Zx4%}B5IN_3yq&@*&ubn)0?g4G-%L)CZppWw_p7E7eEYPQb6cfMJ~ zuX~G2dtBD!qwg7BLK`~~2PO0Vc=}3h$#O_9ex&didWUw=OGamFxbozPCWL|d3y&u> z_gRyH4l7pZS!zc_j_)P)ecrM$zSLY8J_VE%QoxdBPM;B*#kvc5P@YotGMs8ZuhksM zVO+sEn=UulRCaT!mwGd%Kag3e-t+TDsm%06^1!~E{L4G#aTLbO*oSXM_wfq%P0BBM zI9+v3o`=Bq$$#~G1Ov!rkTC37QM=^81NaSN6t5H0R=d7D3nd>KoInNkO9ebgzjvfH zPKR4by_p}uww6Ov#6p~46-pw5=~1F75XIFgj{o;m|F^pO*Z?wi{bv`8zU|5xd_x9_ z5fvrN{rHhDYKE9kMv$O_is`37MuuK)XX4DUfB&1*}Fv(^rtpI{&8=<&5uNED9DQ9;bIXdWZ`KVNw9lWD9Pu$yY494u>67tXtO6eqErAsZiK)KoGbYmzX zKNg}_-Dv`k>SD(2P!&DXL>!6jyYhOPFvvd6ETcBZeqt=dV=2E7zCVe+oBta42Y)e>H}Q7TMi}zuWk)kfS(>da{DB>SKU3o|M^LV zX*6PA8xicAF6g}Rs4%o)(P!?gR!7r>k+5$M-}f>wib_!Cn-=C$qzTmE60bEYcwkn`@Oe{}cElaQ|p(LW6k z`?T#=?iw2ZR%pjmf40}b_CZ>3mfW#SPYiz3!Q-ed=sCuu=t0Y=>a<5?(<>YDom0e4 zb8)|!EF)Bm^4uwMmxpzrFP2Pw^YxQ+sw|GfyG#|p*qsJ2sv8u46Z7`fO0jQq`hC zvOr1l(r^^brNGb{_ft^BD!6kqa zSA_dy1*B|ACqpbYFuJuK==-s#tF1%r3DvnAm8bOYvnZLNM{XHfL7*)vh4hZ>6uhe6 zHtu$vy=T>Kp@}K-ZaI|tjVr17=sCAERq3m`VIQ>SS2KN?DOEevBV%43L$3)~O7~)YF?O z>f;c)8I!=IEV%n{HBlA=EtrZ%S=H5Pa)C+IBH~^aQ?@Lhf4C!ONADq~8GBd&+dM^} z*|;Ru?(2N>ym;!nExCg}T(>WP`=hf++NPE`(z_E*?vu^fF$sfHY7Q(Lz$3zsaF+@N ztrYBvd^+0f(q&(R6qVvCfw$wX)0~dl4KOeOXQAMlbU~HLgB>ATQXVR+GXonH9runK z_ba8Km%vuG{583N{~Bu-t!{{ECB_QsCrQsN9ADX7^oEyq1Vq!Bikp$D7{JD)^;B!- zWc}MGRL~5JJb@sC-@a0@)Ha%hmI5G+kMt6(iSpXY6t3K4v(W7BZmC;lgM?(e))yDh zA8Qr<)bR`9fsbxeC^vhb)z_|r_eArw+YX#X+ots=<+^oPwK#3h&!qlpkBd43hu2F=CAJqBCTkGbhIfx}CBhi$^jX_gD zhPG&OuCBY~+%MnoGf-u7suc`0I`sszq}j|z3%iesBH*00LE-UD2NCRIz5+N~P+~L* z*+Oyo(H|ew^KZ4BV~@GgxlBX$5J8Jio23U+hF<&hVpshy5`%(7AeT$1?yD+hd06BAV-fpFT*bz;jaZ!5&d~^Ua7pnF((U^&(sGE+k+*Qh&y}}rYX)jIszKQhBte4mJ z^X*!iQ={7zvIDz3M?<}LxkpP-Ssv1cfWk%Z3xletn)_})X1AJhyEz-Udg?Odl|O|7 z9lX`T>QwKH z%H#9Oub?zSqK;1R4@~NJoK7|71o9$uAfEED7?vi_7xGnJGx;ZYujez&m?gh^D_#j1 zYEsf%?#nlkQ5!(EFcWyRRv3A;u(4qgwlt#GTltFd(%CwJ+dvFhHE)w*i(ST!o_A0# zdPMM2vrogZ2U!;9=aKF^v5A=2`Y)-9@Pt6-d`0-Wbfxz%Ysocg4+(CzA-^bSaQmq$yuWrWELjHh)*8G^6>v1M${{Im*)B|Jx?6oV%Jof? zkv!{}tc$Eui@f@Jc$3lh@i>#{kLnjgD?%7tngOrqIOlzC_OWFL38?81L5;D2E|anM z9aEQ!5BJ*EV&k8N1Fq0Uxa@mro0oW9#saSQf7BHV^W%<~sg2qO?$<%k*03`us$a5I zD7*|2P?D?lVc(60--<5>%ckJ8$3m{>hyvuao*2d%L&IZ8jdXeN|siIzP66YNRLYhBfZ!5r6h56~fLM^2lK+`#LokLP6 zoR%sw?D8vzm7cmC4pC`KrO7`LQ7to@kGO8%?(c4_$(&bBV|E>^tn{AjBgBfk9?a{0 zji%VFWSc0QU@OA;IxU(B5`}9JHSSh6&nIUxM~4&QYPA(UE$XInqszK`W_1J1_VV!i zu1RYHt!Lz@ICwbjrJgo$vixOgOn*7yS%vf?o!hQE6WPePDc3b>Z~GOY6^o`M88?gu z+M4o)5aggfWZDrJd{j3qqy(hYPyR|MGV0L#p6Daom@fADN=T>?Z{q%XWSqF70orH) zV$)}{AijyihBaA>@oqVg*b1?P4%N$H!(zIsUd?RjOGvy!zU+W12B}DSGAt&N${&rMszpvDx=`dHhxS?8Vy#Cn)N_B*3!Ilsmtt+`l9pVk=%RnEH+?$ zm;m0Yn#H?ZO#_@nffJ0ij+vv~gY<9#e_lTl^_>v@mLbctP&n`7*iU&gBgVOy?xq*aPTGV-Hhvz2 zs}anx0x;KnYsc}OmG?14q6#J^j*+Bni49+fh_YTkHV+^I4iB|S-^u!3&GmYP zbBfF9TXF6t%TA?OUpSe?1tZD3prv#H?9L;xNpH%G8;Qc3?A-XXDYiHi^JEQNx49l`Fs2%lGcJnVAIBc3 z3UN|@kFfQHu65k zquv2hd_2N6MYyL5OD4$qXb!kodE(X>Ml$5xu6XUYo(zH*CD6-924aIG{)cAD@tPHp zU5Utv$fr@9S7WE$32Q!{k=WdmDz)FbO2_~}YU%|tii-RXu?VjgL$jm_li7bqL$a%1 z#WIVz%#B9lV>Q`2CKWy`&k$t!jTB&L;YZq z1K&duD@&DC5Gf3{zf%|{1a_6soT3mZ47~%;vHwp*@mE1E*)KPB1uOX@WzoXKj{!>y zkdcqOgpU|meC4SHJsB7CG3fIMkilwLfI%lfN!@mUg^YaTIXUc!^oAUojWj5dRO6Ka zAH`X>5HTWKg9veqS42w71P~xQBdi>R_GgA691xB$lip8R6=A#};(~gk+Duj24^SZO z7nDdO&cKKw-SHH0+3l>u%?K7p(*TQ0Dgr?X2zkbM$VBmitZBrE>=7nH5KSQ(ydU9E z&QQeF_S59SZ~%dSB0`M@O5YknUaFK|kQtuRhBU$wMT8nAWHTp(yg?dqN$ya3XE5TH zogRg*AQ6dM5Fu{^aVehG9WVGh$>cxH{*Sl+?}Nm@8~}SY;KcQN^jyh;65K^tB%iDs prz!ZKR?sHL0CfESOzl{IXtGl=9p9}*signing up for a p
  • Cadre
  • Load Impact
  • Kloudless
    • -
  • Lights On Software
    • +
  • Lights On Software
    • diff --git a/mkdocs/search_index.json b/mkdocs/search_index.json index 6a4eabb38..a33f1ebe1 100644 --- a/mkdocs/search_index.json +++ b/mkdocs/search_index.json @@ -1362,7 +1362,7 @@ }, { "location": "/api-guide/serializers/", - "text": "Serializers\n\n\n\n\nExpanding the usefulness of the serializers is something that we would\nlike to address. However, it's not a trivial problem, and it\nwill take some serious design work.\n\n\n\u2014 Russell Keith-Magee, \nDjango users group\n\n\n\n\nSerializers allow complex data such as querysets and model instances to be converted to native Python datatypes that can then be easily rendered into \nJSON\n, \nXML\n or other content types. Serializers also provide deserialization, allowing parsed data to be converted back into complex types, after first validating the incoming data.\n\n\nThe serializers in REST framework work very similarly to Django's \nForm\n and \nModelForm\n classes. We provide a \nSerializer\n class which gives you a powerful, generic way to control the output of your responses, as well as a \nModelSerializer\n class which provides a useful shortcut for creating serializers that deal with model instances and querysets.\n\n\nDeclaring Serializers\n\n\nLet's start by creating a simple object we can use for example purposes:\n\n\nfrom datetime import datetime\n\nclass Comment(object):\n def __init__(self, email, content, created=None):\n self.email = email\n self.content = content\n self.created = created or datetime.now()\n\ncomment = Comment(email='leila@example.com', content='foo bar')\n\n\n\nWe'll declare a serializer that we can use to serialize and deserialize data that corresponds to \nComment\n objects.\n\n\nDeclaring a serializer looks very similar to declaring a form:\n\n\nfrom rest_framework import serializers\n\nclass CommentSerializer(serializers.Serializer):\n email = serializers.EmailField()\n content = serializers.CharField(max_length=200)\n created = serializers.DateTimeField()\n\n\n\nSerializing objects\n\n\nWe can now use \nCommentSerializer\n to serialize a comment, or list of comments. Again, using the \nSerializer\n class looks a lot like using a \nForm\n class.\n\n\nserializer = CommentSerializer(comment)\nserializer.data\n# {'email': 'leila@example.com', 'content': 'foo bar', 'created': '2016-01-27T15:17:10.375877'}\n\n\n\nAt this point we've translated the model instance into Python native datatypes. To finalise the serialization process we render the data into \njson\n.\n\n\nfrom rest_framework.renderers import JSONRenderer\n\njson = JSONRenderer().render(serializer.data)\njson\n# b'{\"email\":\"leila@example.com\",\"content\":\"foo bar\",\"created\":\"2016-01-27T15:17:10.375877\"}'\n\n\n\nDeserializing objects\n\n\nDeserialization is similar. First we parse a stream into Python native datatypes...\n\n\nimport io\nfrom rest_framework.parsers import JSONParser\n\nstream = io.BytesIO(json)\ndata = JSONParser().parse(stream)\n\n\n\n...then we restore those native datatypes into a dictionary of validated data.\n\n\nserializer = CommentSerializer(data=data)\nserializer.is_valid()\n# True\nserializer.validated_data\n# {'content': 'foo bar', 'email': 'leila@example.com', 'created': datetime.datetime(2012, 08, 22, 16, 20, 09, 822243)}\n\n\n\nSaving instances\n\n\nIf we want to be able to return complete object instances based on the validated data we need to implement one or both of the \n.create()\n and \n.update()\n methods. For example:\n\n\nclass CommentSerializer(serializers.Serializer):\n email = serializers.EmailField()\n content = serializers.CharField(max_length=200)\n created = serializers.DateTimeField()\n\n def create(self, validated_data):\n return Comment(**validated_data)\n\n def update(self, instance, validated_data):\n instance.email = validated_data.get('email', instance.email)\n instance.content = validated_data.get('content', instance.content)\n instance.created = validated_data.get('created', instance.created)\n return instance\n\n\n\nIf your object instances correspond to Django models you'll also want to ensure that these methods save the object to the database. For example, if \nComment\n was a Django model, the methods might look like this:\n\n\n def create(self, validated_data):\n return Comment.objects.create(**validated_data)\n\n def update(self, instance, validated_data):\n instance.email = validated_data.get('email', instance.email)\n instance.content = validated_data.get('content', instance.content)\n instance.created = validated_data.get('created', instance.created)\n instance.save()\n return instance\n\n\n\nNow when deserializing data, we can call \n.save()\n to return an object instance, based on the validated data.\n\n\ncomment = serializer.save()\n\n\n\nCalling \n.save()\n will either create a new instance, or update an existing instance, depending on if an existing instance was passed when instantiating the serializer class:\n\n\n# .save() will create a new instance.\nserializer = CommentSerializer(data=data)\n\n# .save() will update the existing `comment` instance.\nserializer = CommentSerializer(comment, data=data)\n\n\n\nBoth the \n.create()\n and \n.update()\n methods are optional. You can implement either neither, one, or both of them, depending on the use-case for your serializer class.\n\n\nPassing additional attributes to \n.save()\n\n\nSometimes you'll want your view code to be able to inject additional data at the point of saving the instance. This additional data might include information like the current user, the current time, or anything else that is not part of the request data.\n\n\nYou can do so by including additional keyword arguments when calling \n.save()\n. For example:\n\n\nserializer.save(owner=request.user)\n\n\n\nAny additional keyword arguments will be included in the \nvalidated_data\n argument when \n.create()\n or \n.update()\n are called.\n\n\nOverriding \n.save()\n directly.\n\n\nIn some cases the \n.create()\n and \n.update()\n method names may not be meaningful. For example, in a contact form we may not be creating new instances, but instead sending an email or other message.\n\n\nIn these cases you might instead choose to override \n.save()\n directly, as being more readable and meaningful.\n\n\nFor example:\n\n\nclass ContactForm(serializers.Serializer):\n email = serializers.EmailField()\n message = serializers.CharField()\n\n def save(self):\n email = self.validated_data['email']\n message = self.validated_data['message']\n send_email(from=email, message=message)\n\n\n\nNote that in the case above we're now having to access the serializer \n.validated_data\n property directly.\n\n\nValidation\n\n\nWhen deserializing data, you always need to call \nis_valid()\n before attempting to access the validated data, or save an object instance. If any validation errors occur, the \n.errors\n property will contain a dictionary representing the resulting error messages. For example:\n\n\nserializer = CommentSerializer(data={'email': 'foobar', 'content': 'baz'})\nserializer.is_valid()\n# False\nserializer.errors\n# {'email': [u'Enter a valid e-mail address.'], 'created': [u'This field is required.']}\n\n\n\nEach key in the dictionary will be the field name, and the values will be lists of strings of any error messages corresponding to that field. The \nnon_field_errors\n key may also be present, and will list any general validation errors. The name of the \nnon_field_errors\n key may be customized using the \nNON_FIELD_ERRORS_KEY\n REST framework setting.\n\n\nWhen deserializing a list of items, errors will be returned as a list of dictionaries representing each of the deserialized items.\n\n\nRaising an exception on invalid data\n\n\nThe \n.is_valid()\n method takes an optional \nraise_exception\n flag that will cause it to raise a \nserializers.ValidationError\n exception if there are validation errors.\n\n\nThese exceptions are automatically dealt with by the default exception handler that REST framework provides, and will return \nHTTP 400 Bad Request\n responses by default.\n\n\n# Return a 400 response if the data was invalid.\nserializer.is_valid(raise_exception=True)\n\n\n\nField-level validation\n\n\nYou can specify custom field-level validation by adding \n.validate_\n methods to your \nSerializer\n subclass. These are similar to the \n.clean_\n methods on Django forms.\n\n\nThese methods take a single argument, which is the field value that requires validation.\n\n\nYour \nvalidate_\n methods should return the validated value or raise a \nserializers.ValidationError\n. For example:\n\n\nfrom rest_framework import serializers\n\nclass BlogPostSerializer(serializers.Serializer):\n title = serializers.CharField(max_length=100)\n content = serializers.CharField()\n\n def validate_title(self, value):\n \"\"\"\n Check that the blog post is about Django.\n \"\"\"\n if 'django' not in value.lower():\n raise serializers.ValidationError(\"Blog post is not about Django\")\n return value\n\n\n\n\n\nNote:\n If your \n\n is declared on your serializer with the parameter \nrequired=False\n then this validation step will not take place if the field is not included.\n\n\n\n\nObject-level validation\n\n\nTo do any other validation that requires access to multiple fields, add a method called \n.validate()\n to your \nSerializer\n subclass. This method takes a single argument, which is a dictionary of field values. It should raise a \nserializers.ValidationError\n if necessary, or just return the validated values. For example:\n\n\nfrom rest_framework import serializers\n\nclass EventSerializer(serializers.Serializer):\n description = serializers.CharField(max_length=100)\n start = serializers.DateTimeField()\n finish = serializers.DateTimeField()\n\n def validate(self, data):\n \"\"\"\n Check that the start is before the stop.\n \"\"\"\n if data['start'] > data['finish']:\n raise serializers.ValidationError(\"finish must occur after start\")\n return data\n\n\n\nValidators\n\n\nIndividual fields on a serializer can include validators, by declaring them on the field instance, for example:\n\n\ndef multiple_of_ten(value):\n if value % 10 != 0:\n raise serializers.ValidationError('Not a multiple of ten')\n\nclass GameRecord(serializers.Serializer):\n score = IntegerField(validators=[multiple_of_ten])\n ...\n\n\n\nSerializer classes can also include reusable validators that are applied to the complete set of field data. These validators are included by declaring them on an inner \nMeta\n class, like so:\n\n\nclass EventSerializer(serializers.Serializer):\n name = serializers.CharField()\n room_number = serializers.IntegerField(choices=[101, 102, 103, 201])\n date = serializers.DateField()\n\n class Meta:\n # Each room only has one event per day.\n validators = UniqueTogetherValidator(\n queryset=Event.objects.all(),\n fields=['room_number', 'date']\n )\n\n\n\nFor more information see the \nvalidators documentation\n.\n\n\nAccessing the initial data and instance\n\n\nWhen passing an initial object or queryset to a serializer instance, the object will be made available as \n.instance\n. If no initial object is passed then the \n.instance\n attribute will be \nNone\n.\n\n\nWhen passing data to a serializer instance, the unmodified data will be made available as \n.initial_data\n. If the data keyword argument is not passed then the \n.initial_data\n attribute will not exist.\n\n\nPartial updates\n\n\nBy default, serializers must be passed values for all required fields or they will raise validation errors. You can use the \npartial\n argument in order to allow partial updates.\n\n\n# Update `comment` with partial data\nserializer = CommentSerializer(comment, data={'content': u'foo bar'}, partial=True)\n\n\n\nDealing with nested objects\n\n\nThe previous examples are fine for dealing with objects that only have simple datatypes, but sometimes we also need to be able to represent more complex objects, where some of the attributes of an object might not be simple datatypes such as strings, dates or integers.\n\n\nThe \nSerializer\n class is itself a type of \nField\n, and can be used to represent relationships where one object type is nested inside another.\n\n\nclass UserSerializer(serializers.Serializer):\n email = serializers.EmailField()\n username = serializers.CharField(max_length=100)\n\nclass CommentSerializer(serializers.Serializer):\n user = UserSerializer()\n content = serializers.CharField(max_length=200)\n created = serializers.DateTimeField()\n\n\n\nIf a nested representation may optionally accept the \nNone\n value you should pass the \nrequired=False\n flag to the nested serializer.\n\n\nclass CommentSerializer(serializers.Serializer):\n user = UserSerializer(required=False) # May be an anonymous user.\n content = serializers.CharField(max_length=200)\n created = serializers.DateTimeField()\n\n\n\nSimilarly if a nested representation should be a list of items, you should pass the \nmany=True\n flag to the nested serialized.\n\n\nclass CommentSerializer(serializers.Serializer):\n user = UserSerializer(required=False)\n edits = EditItemSerializer(many=True) # A nested list of 'edit' items.\n content = serializers.CharField(max_length=200)\n created = serializers.DateTimeField()\n\n\n\nWritable nested representations\n\n\nWhen dealing with nested representations that support deserializing the data, any errors with nested objects will be nested under the field name of the nested object.\n\n\nserializer = CommentSerializer(data={'user': {'email': 'foobar', 'username': 'doe'}, 'content': 'baz'})\nserializer.is_valid()\n# False\nserializer.errors\n# {'user': {'email': [u'Enter a valid e-mail address.']}, 'created': [u'This field is required.']}\n\n\n\nSimilarly, the \n.validated_data\n property will include nested data structures.\n\n\nWriting \n.create()\n methods for nested representations\n\n\nIf you're supporting writable nested representations you'll need to write \n.create()\n or \n.update()\n methods that handle saving multiple objects.\n\n\nThe following example demonstrates how you might handle creating a user with a nested profile object.\n\n\nclass UserSerializer(serializers.ModelSerializer):\n profile = ProfileSerializer()\n\n class Meta:\n model = User\n fields = ('username', 'email', 'profile')\n\n def create(self, validated_data):\n profile_data = validated_data.pop('profile')\n user = User.objects.create(**validated_data)\n Profile.objects.create(user=user, **profile_data)\n return user\n\n\n\nWriting \n.update()\n methods for nested representations\n\n\nFor updates you'll want to think carefully about how to handle updates to relationships. For example if the data for the relationship is \nNone\n, or not provided, which of the following should occur?\n\n\n\n\nSet the relationship to \nNULL\n in the database.\n\n\nDelete the associated instance.\n\n\nIgnore the data and leave the instance as it is.\n\n\nRaise a validation error.\n\n\n\n\nHere's an example for an \n.update()\n method on our previous \nUserSerializer\n class.\n\n\n def update(self, instance, validated_data):\n profile_data = validated_data.pop('profile')\n # Unless the application properly enforces that this field is\n # always set, the follow could raise a `DoesNotExist`, which\n # would need to be handled.\n profile = instance.profile\n\n instance.username = validated_data.get('username', instance.username)\n instance.email = validated_data.get('email', instance.email)\n instance.save()\n\n profile.is_premium_member = profile_data.get(\n 'is_premium_member',\n profile.is_premium_member\n )\n profile.has_support_contract = profile_data.get(\n 'has_support_contract',\n profile.has_support_contract\n )\n profile.save()\n\n return instance\n\n\n\nBecause the behavior of nested creates and updates can be ambiguous, and may require complex dependencies between related models, REST framework 3 requires you to always write these methods explicitly. The default \nModelSerializer\n \n.create()\n and \n.update()\n methods do not include support for writable nested representations.\n\n\nThere are however, third-party packages available such as \nDRF Writable Nested\n that support automatic writable nested representations.\n\n\nHandling saving related instances in model manager classes\n\n\nAn alternative to saving multiple related instances in the serializer is to write custom model manager classes that handle creating the correct instances.\n\n\nFor example, suppose we wanted to ensure that \nUser\n instances and \nProfile\n instances are always created together as a pair. We might write a custom manager class that looks something like this:\n\n\nclass UserManager(models.Manager):\n ...\n\n def create(self, username, email, is_premium_member=False, has_support_contract=False):\n user = User(username=username, email=email)\n user.save()\n profile = Profile(\n user=user,\n is_premium_member=is_premium_member,\n has_support_contract=has_support_contract\n )\n profile.save()\n return user\n\n\n\nThis manager class now more nicely encapsulates that user instances and profile instances are always created at the same time. Our \n.create()\n method on the serializer class can now be re-written to use the new manager method.\n\n\ndef create(self, validated_data):\n return User.objects.create(\n username=validated_data['username'],\n email=validated_data['email']\n is_premium_member=validated_data['profile']['is_premium_member']\n has_support_contract=validated_data['profile']['has_support_contract']\n )\n\n\n\nFor more details on this approach see the Django documentation on \nmodel managers\n, and \nthis blogpost on using model and manager classes\n.\n\n\nDealing with multiple objects\n\n\nThe \nSerializer\n class can also handle serializing or deserializing lists of objects.\n\n\nSerializing multiple objects\n\n\nTo serialize a queryset or list of objects instead of a single object instance, you should pass the \nmany=True\n flag when instantiating the serializer. You can then pass a queryset or list of objects to be serialized.\n\n\nqueryset = Book.objects.all()\nserializer = BookSerializer(queryset, many=True)\nserializer.data\n# [\n# {'id': 0, 'title': 'The electric kool-aid acid test', 'author': 'Tom Wolfe'},\n# {'id': 1, 'title': 'If this is a man', 'author': 'Primo Levi'},\n# {'id': 2, 'title': 'The wind-up bird chronicle', 'author': 'Haruki Murakami'}\n# ]\n\n\n\nDeserializing multiple objects\n\n\nThe default behavior for deserializing multiple objects is to support multiple object creation, but not support multiple object updates. For more information on how to support or customize either of these cases, see the \nListSerializer\n documentation below.\n\n\nIncluding extra context\n\n\nThere are some cases where you need to provide extra context to the serializer in addition to the object being serialized. One common case is if you're using a serializer that includes hyperlinked relations, which requires the serializer to have access to the current request so that it can properly generate fully qualified URLs.\n\n\nYou can provide arbitrary additional context by passing a \ncontext\n argument when instantiating the serializer. For example:\n\n\nserializer = AccountSerializer(account, context={'request': request})\nserializer.data\n# {'id': 6, 'owner': u'denvercoder9', 'created': datetime.datetime(2013, 2, 12, 09, 44, 56, 678870), 'details': 'http://example.com/accounts/6/details'}\n\n\n\nThe context dictionary can be used within any serializer field logic, such as a custom \n.to_representation()\n method, by accessing the \nself.context\n attribute.\n\n\n\n\nModelSerializer\n\n\nOften you'll want serializer classes that map closely to Django model definitions.\n\n\nThe \nModelSerializer\n class provides a shortcut that lets you automatically create a \nSerializer\n class with fields that correspond to the Model fields.\n\n\nThe \nModelSerializer\n class is the same as a regular \nSerializer\n class, except that\n:\n\n\n\n\nIt will automatically generate a set of fields for you, based on the model.\n\n\nIt will automatically generate validators for the serializer, such as unique_together validators.\n\n\nIt includes simple default implementations of \n.create()\n and \n.update()\n.\n\n\n\n\nDeclaring a \nModelSerializer\n looks like this:\n\n\nclass AccountSerializer(serializers.ModelSerializer):\n class Meta:\n model = Account\n fields = ('id', 'account_name', 'users', 'created')\n\n\n\nBy default, all the model fields on the class will be mapped to a corresponding serializer fields.\n\n\nAny relationships such as foreign keys on the model will be mapped to \nPrimaryKeyRelatedField\n. Reverse relationships are not included by default unless explicitly included as specified in the \nserializer relations\n documentation.\n\n\nInspecting a \nModelSerializer\n\n\nSerializer classes generate helpful verbose representation strings, that allow you to fully inspect the state of their fields. This is particularly useful when working with \nModelSerializers\n where you want to determine what set of fields and validators are being automatically created for you.\n\n\nTo do so, open the Django shell, using \npython manage.py shell\n, then import the serializer class, instantiate it, and print the object representation\u2026\n\n\n>>> from myapp.serializers import AccountSerializer\n>>> serializer = AccountSerializer()\n>>> print(repr(serializer))\nAccountSerializer():\n id = IntegerField(label='ID', read_only=True)\n name = CharField(allow_blank=True, max_length=100, required=False)\n owner = PrimaryKeyRelatedField(queryset=User.objects.all())\n\n\n\nSpecifying which fields to include\n\n\nIf you only want a subset of the default fields to be used in a model serializer, you can do so using \nfields\n or \nexclude\n options, just as you would with a \nModelForm\n. It is strongly recommended that you explicitly set all fields that should be serialized using the \nfields\n attribute. This will make it less likely to result in unintentionally exposing data when your models change.\n\n\nFor example:\n\n\nclass AccountSerializer(serializers.ModelSerializer):\n class Meta:\n model = Account\n fields = ('id', 'account_name', 'users', 'created')\n\n\n\nYou can also set the \nfields\n attribute to the special value \n'__all__'\n to indicate that all fields in the model should be used.\n\n\nFor example:\n\n\nclass AccountSerializer(serializers.ModelSerializer):\n class Meta:\n model = Account\n fields = '__all__'\n\n\n\nYou can set the \nexclude\n attribute to a list of fields to be excluded from the serializer.\n\n\nFor example:\n\n\nclass AccountSerializer(serializers.ModelSerializer):\n class Meta:\n model = Account\n exclude = ('users',)\n\n\n\nIn the example above, if the \nAccount\n model had 3 fields \naccount_name\n, \nusers\n, and \ncreated\n, this will result in the fields \naccount_name\n and \ncreated\n to be serialized.\n\n\nThe names in the \nfields\n and \nexclude\n attributes will normally map to model fields on the model class.\n\n\nAlternatively names in the \nfields\n options can map to properties or methods which take no arguments that exist on the model class.\n\n\nSince version 3.3.0, it is \nmandatory\n to provide one of the attributes \nfields\n or \nexclude\n.\n\n\nSpecifying nested serialization\n\n\nThe default \nModelSerializer\n uses primary keys for relationships, but you can also easily generate nested representations using the \ndepth\n option:\n\n\nclass AccountSerializer(serializers.ModelSerializer):\n class Meta:\n model = Account\n fields = ('id', 'account_name', 'users', 'created')\n depth = 1\n\n\n\nThe \ndepth\n option should be set to an integer value that indicates the depth of relationships that should be traversed before reverting to a flat representation.\n\n\nIf you want to customize the way the serialization is done you'll need to define the field yourself.\n\n\nSpecifying fields explicitly\n\n\nYou can add extra fields to a \nModelSerializer\n or override the default fields by declaring fields on the class, just as you would for a \nSerializer\n class.\n\n\nclass AccountSerializer(serializers.ModelSerializer):\n url = serializers.CharField(source='get_absolute_url', read_only=True)\n groups = serializers.PrimaryKeyRelatedField(many=True)\n\n class Meta:\n model = Account\n\n\n\nExtra fields can correspond to any property or callable on the model.\n\n\nSpecifying read only fields\n\n\nYou may wish to specify multiple fields as read-only. Instead of adding each field explicitly with the \nread_only=True\n attribute, you may use the shortcut Meta option, \nread_only_fields\n.\n\n\nThis option should be a list or tuple of field names, and is declared as follows:\n\n\nclass AccountSerializer(serializers.ModelSerializer):\n class Meta:\n model = Account\n fields = ('id', 'account_name', 'users', 'created')\n read_only_fields = ('account_name',)\n\n\n\nModel fields which have \neditable=False\n set, and \nAutoField\n fields will be set to read-only by default, and do not need to be added to the \nread_only_fields\n option.\n\n\n\n\nNote\n: There is a special-case where a read-only field is part of a \nunique_together\n constraint at the model level. In this case the field is required by the serializer class in order to validate the constraint, but should also not be editable by the user.\n\n\nThe right way to deal with this is to specify the field explicitly on the serializer, providing both the \nread_only=True\n and \ndefault=\u2026\n keyword arguments.\n\n\nOne example of this is a read-only relation to the currently authenticated \nUser\n which is \nunique_together\n with another identifier. In this case you would declare the user field like so:\n\n\nuser = serializers.PrimaryKeyRelatedField(read_only=True, default=serializers.CurrentUserDefault())\n\n\n\nPlease review the \nValidators Documentation\n for details on the \nUniqueTogetherValidator\n and \nCurrentUserDefault\n classes.\n\n\n\n\nAdditional keyword arguments\n\n\nThere is also a shortcut allowing you to specify arbitrary additional keyword arguments on fields, using the \nextra_kwargs\n option. As in the case of \nread_only_fields\n, this means you do not need to explicitly declare the field on the serializer.\n\n\nThis option is a dictionary, mapping field names to a dictionary of keyword arguments. For example:\n\n\nclass CreateUserSerializer(serializers.ModelSerializer):\n class Meta:\n model = User\n fields = ('email', 'username', 'password')\n extra_kwargs = {'password': {'write_only': True}}\n\n def create(self, validated_data):\n user = User(\n email=validated_data['email'],\n username=validated_data['username']\n )\n user.set_password(validated_data['password'])\n user.save()\n return user\n\n\n\nRelational fields\n\n\nWhen serializing model instances, there are a number of different ways you might choose to represent relationships. The default representation for \nModelSerializer\n is to use the primary keys of the related instances.\n\n\nAlternative representations include serializing using hyperlinks, serializing complete nested representations, or serializing with a custom representation.\n\n\nFor full details see the \nserializer relations\n documentation.\n\n\nCustomizing field mappings\n\n\nThe ModelSerializer class also exposes an API that you can override in order to alter how serializer fields are automatically determined when instantiating the serializer.\n\n\nNormally if a \nModelSerializer\n does not generate the fields you need by default then you should either add them to the class explicitly, or simply use a regular \nSerializer\n class instead. However in some cases you may want to create a new base class that defines how the serializer fields are created for any given model.\n\n\n.serializer_field_mapping\n\n\nA mapping of Django model classes to REST framework serializer classes. You can override this mapping to alter the default serializer classes that should be used for each model class.\n\n\n.serializer_related_field\n\n\nThis property should be the serializer field class, that is used for relational fields by default.\n\n\nFor \nModelSerializer\n this defaults to \nPrimaryKeyRelatedField\n.\n\n\nFor \nHyperlinkedModelSerializer\n this defaults to \nserializers.HyperlinkedRelatedField\n.\n\n\nserializer_url_field\n\n\nThe serializer field class that should be used for any \nurl\n field on the serializer.\n\n\nDefaults to \nserializers.HyperlinkedIdentityField\n\n\nserializer_choice_field\n\n\nThe serializer field class that should be used for any choice fields on the serializer.\n\n\nDefaults to \nserializers.ChoiceField\n\n\nThe field_class and field_kwargs API\n\n\nThe following methods are called to determine the class and keyword arguments for each field that should be automatically included on the serializer. Each of these methods should return a two tuple of \n(field_class, field_kwargs)\n.\n\n\n.build_standard_field(self, field_name, model_field)\n\n\nCalled to generate a serializer field that maps to a standard model field.\n\n\nThe default implementation returns a serializer class based on the \nserializer_field_mapping\n attribute.\n\n\n.build_relational_field(self, field_name, relation_info)\n\n\nCalled to generate a serializer field that maps to a relational model field.\n\n\nThe default implementation returns a serializer class based on the \nserializer_relational_field\n attribute.\n\n\nThe \nrelation_info\n argument is a named tuple, that contains \nmodel_field\n, \nrelated_model\n, \nto_many\n and \nhas_through_model\n properties.\n\n\n.build_nested_field(self, field_name, relation_info, nested_depth)\n\n\nCalled to generate a serializer field that maps to a relational model field, when the \ndepth\n option has been set.\n\n\nThe default implementation dynamically creates a nested serializer class based on either \nModelSerializer\n or \nHyperlinkedModelSerializer\n.\n\n\nThe \nnested_depth\n will be the value of the \ndepth\n option, minus one.\n\n\nThe \nrelation_info\n argument is a named tuple, that contains \nmodel_field\n, \nrelated_model\n, \nto_many\n and \nhas_through_model\n properties.\n\n\n.build_property_field(self, field_name, model_class)\n\n\nCalled to generate a serializer field that maps to a property or zero-argument method on the model class.\n\n\nThe default implementation returns a \nReadOnlyField\n class.\n\n\n.build_url_field(self, field_name, model_class)\n\n\nCalled to generate a serializer field for the serializer's own \nurl\n field. The default implementation returns a \nHyperlinkedIdentityField\n class.\n\n\n.build_unknown_field(self, field_name, model_class)\n\n\nCalled when the field name did not map to any model field or model property.\nThe default implementation raises an error, although subclasses may customize this behavior.\n\n\n\n\nHyperlinkedModelSerializer\n\n\nThe \nHyperlinkedModelSerializer\n class is similar to the \nModelSerializer\n class except that it uses hyperlinks to represent relationships, rather than primary keys.\n\n\nBy default the serializer will include a \nurl\n field instead of a primary key field.\n\n\nThe url field will be represented using a \nHyperlinkedIdentityField\n serializer field, and any relationships on the model will be represented using a \nHyperlinkedRelatedField\n serializer field.\n\n\nYou can explicitly include the primary key by adding it to the \nfields\n option, for example:\n\n\nclass AccountSerializer(serializers.HyperlinkedModelSerializer):\n class Meta:\n model = Account\n fields = ('url', 'id', 'account_name', 'users', 'created')\n\n\n\nAbsolute and relative URLs\n\n\nWhen instantiating a \nHyperlinkedModelSerializer\n you must include the current\n\nrequest\n in the serializer context, for example:\n\n\nserializer = AccountSerializer(queryset, context={'request': request})\n\n\n\nDoing so will ensure that the hyperlinks can include an appropriate hostname,\nso that the resulting representation uses fully qualified URLs, such as:\n\n\nhttp://api.example.com/accounts/1/\n\n\n\nRather than relative URLs, such as:\n\n\n/accounts/1/\n\n\n\nIf you \ndo\n want to use relative URLs, you should explicitly pass \n{'request': None}\n\nin the serializer context.\n\n\nHow hyperlinked views are determined\n\n\nThere needs to be a way of determining which views should be used for hyperlinking to model instances.\n\n\nBy default hyperlinks are expected to correspond to a view name that matches the style \n'{model_name}-detail'\n, and looks up the instance by a \npk\n keyword argument.\n\n\nYou can override a URL field view name and lookup field by using either, or both of, the \nview_name\n and \nlookup_field\n options in the \nextra_kwargs\n setting, like so:\n\n\nclass AccountSerializer(serializers.HyperlinkedModelSerializer):\n class Meta:\n model = Account\n fields = ('account_url', 'account_name', 'users', 'created')\n extra_kwargs = {\n 'url': {'view_name': 'accounts', 'lookup_field': 'account_name'},\n 'users': {'lookup_field': 'username'}\n }\n\n\n\nAlternatively you can set the fields on the serializer explicitly. For example:\n\n\nclass AccountSerializer(serializers.HyperlinkedModelSerializer):\n url = serializers.HyperlinkedIdentityField(\n view_name='accounts',\n lookup_field='slug'\n )\n users = serializers.HyperlinkedRelatedField(\n view_name='user-detail',\n lookup_field='username',\n many=True,\n read_only=True\n )\n\n class Meta:\n model = Account\n fields = ('url', 'account_name', 'users', 'created')\n\n\n\n\n\nTip\n: Properly matching together hyperlinked representations and your URL conf can sometimes be a bit fiddly. Printing the \nrepr\n of a \nHyperlinkedModelSerializer\n instance is a particularly useful way to inspect exactly which view names and lookup fields the relationships are expected to map too.\n\n\n\n\nChanging the URL field name\n\n\nThe name of the URL field defaults to 'url'. You can override this globally, by using the \nURL_FIELD_NAME\n setting.\n\n\n\n\nListSerializer\n\n\nThe \nListSerializer\n class provides the behavior for serializing and validating multiple objects at once. You won't \ntypically\n need to use \nListSerializer\n directly, but should instead simply pass \nmany=True\n when instantiating a serializer.\n\n\nWhen a serializer is instantiated and \nmany=True\n is passed, a \nListSerializer\n instance will be created. The serializer class then becomes a child of the parent \nListSerializer\n\n\nThe following argument can also be passed to a \nListSerializer\n field or a serializer that is passed \nmany=True\n:\n\n\nallow_empty\n\n\nThis is \nTrue\n by default, but can be set to \nFalse\n if you want to disallow empty lists as valid input.\n\n\nCustomizing \nListSerializer\n behavior\n\n\nThere \nare\n a few use cases when you might want to customize the \nListSerializer\n behavior. For example:\n\n\n\n\nYou want to provide particular validation of the lists, such as checking that one element does not conflict with another element in a list.\n\n\nYou want to customize the create or update behavior of multiple objects.\n\n\n\n\nFor these cases you can modify the class that is used when \nmany=True\n is passed, by using the \nlist_serializer_class\n option on the serializer \nMeta\n class.\n\n\nFor example:\n\n\nclass CustomListSerializer(serializers.ListSerializer):\n ...\n\nclass CustomSerializer(serializers.Serializer):\n ...\n class Meta:\n list_serializer_class = CustomListSerializer\n\n\n\nCustomizing multiple create\n\n\nThe default implementation for multiple object creation is to simply call \n.create()\n for each item in the list. If you want to customize this behavior, you'll need to customize the \n.create()\n method on \nListSerializer\n class that is used when \nmany=True\n is passed.\n\n\nFor example:\n\n\nclass BookListSerializer(serializers.ListSerializer):\n def create(self, validated_data):\n books = [Book(**item) for item in validated_data]\n return Book.objects.bulk_create(books)\n\nclass BookSerializer(serializers.Serializer):\n ...\n class Meta:\n list_serializer_class = BookListSerializer\n\n\n\nCustomizing multiple update\n\n\nBy default the \nListSerializer\n class does not support multiple updates. This is because the behavior that should be expected for insertions and deletions is ambiguous.\n\n\nTo support multiple updates you'll need to do so explicitly. When writing your multiple update code make sure to keep the following in mind:\n\n\n\n\nHow do you determine which instance should be updated for each item in the list of data?\n\n\nHow should insertions be handled? Are they invalid, or do they create new objects?\n\n\nHow should removals be handled? Do they imply object deletion, or removing a relationship? Should they be silently ignored, or are they invalid?\n\n\nHow should ordering be handled? Does changing the position of two items imply any state change or is it ignored?\n\n\n\n\nYou will need to add an explicit \nid\n field to the instance serializer. The default implicitly-generated \nid\n field is marked as \nread_only\n. This causes it to be removed on updates. Once you declare it explicitly, it will be available in the list serializer's \nupdate\n method.\n\n\nHere's an example of how you might choose to implement multiple updates:\n\n\nclass BookListSerializer(serializers.ListSerializer):\n def update(self, instance, validated_data):\n # Maps for id->instance and id->data item.\n book_mapping = {book.id: book for book in instance}\n data_mapping = {item['id']: item for item in validated_data}\n\n # Perform creations and updates.\n ret = []\n for book_id, data in data_mapping.items():\n book = book_mapping.get(book_id, None)\n if book is None:\n ret.append(self.child.create(data))\n else:\n ret.append(self.child.update(book, data))\n\n # Perform deletions.\n for book_id, book in book_mapping.items():\n if book_id not in data_mapping:\n book.delete()\n\n return ret\n\nclass BookSerializer(serializers.Serializer):\n # We need to identify elements in the list using their primary key,\n # so use a writable field here, rather than the default which would be read-only.\n id = serializers.IntegerField()\n ...\n\n class Meta:\n list_serializer_class = BookListSerializer\n\n\n\nIt is possible that a third party package may be included alongside the 3.1 release that provides some automatic support for multiple update operations, similar to the \nallow_add_remove\n behavior that was present in REST framework 2.\n\n\nCustomizing ListSerializer initialization\n\n\nWhen a serializer with \nmany=True\n is instantiated, we need to determine which arguments and keyword arguments should be passed to the \n.__init__()\n method for both the child \nSerializer\n class, and for the parent \nListSerializer\n class.\n\n\nThe default implementation is to pass all arguments to both classes, except for \nvalidators\n, and any custom keyword arguments, both of which are assumed to be intended for the child serializer class.\n\n\nOccasionally you might need to explicitly specify how the child and parent classes should be instantiated when \nmany=True\n is passed. You can do so by using the \nmany_init\n class method.\n\n\n @classmethod\n def many_init(cls, *args, **kwargs):\n # Instantiate the child serializer.\n kwargs['child'] = cls()\n # Instantiate the parent list serializer.\n return CustomListSerializer(*args, **kwargs)\n\n\n\n\n\nBaseSerializer\n\n\nBaseSerializer\n class that can be used to easily support alternative serialization and deserialization styles.\n\n\nThis class implements the same basic API as the \nSerializer\n class:\n\n\n\n\n.data\n - Returns the outgoing primitive representation.\n\n\n.is_valid()\n - Deserializes and validates incoming data.\n\n\n.validated_data\n - Returns the validated incoming data.\n\n\n.errors\n - Returns any errors during validation.\n\n\n.save()\n - Persists the validated data into an object instance.\n\n\n\n\nThere are four methods that can be overridden, depending on what functionality you want the serializer class to support:\n\n\n\n\n.to_representation()\n - Override this to support serialization, for read operations.\n\n\n.to_internal_value()\n - Override this to support deserialization, for write operations.\n\n\n.create()\n and \n.update()\n - Override either or both of these to support saving instances.\n\n\n\n\nBecause this class provides the same interface as the \nSerializer\n class, you can use it with the existing generic class-based views exactly as you would for a regular \nSerializer\n or \nModelSerializer\n.\n\n\nThe only difference you'll notice when doing so is the \nBaseSerializer\n classes will not generate HTML forms in the browsable API. This is because the data they return does not include all the field information that would allow each field to be rendered into a suitable HTML input.\n\n\nRead-only \nBaseSerializer\n classes\n\n\nTo implement a read-only serializer using the \nBaseSerializer\n class, we just need to override the \n.to_representation()\n method. Let's take a look at an example using a simple Django model:\n\n\nclass HighScore(models.Model):\n created = models.DateTimeField(auto_now_add=True)\n player_name = models.CharField(max_length=10)\n score = models.IntegerField()\n\n\n\nIt's simple to create a read-only serializer for converting \nHighScore\n instances into primitive data types.\n\n\nclass HighScoreSerializer(serializers.BaseSerializer):\n def to_representation(self, obj):\n return {\n 'score': obj.score,\n 'player_name': obj.player_name\n }\n\n\n\nWe can now use this class to serialize single \nHighScore\n instances:\n\n\n@api_view(['GET'])\ndef high_score(request, pk):\n instance = HighScore.objects.get(pk=pk)\n serializer = HighScoreSerializer(instance)\n return Response(serializer.data)\n\n\n\nOr use it to serialize multiple instances:\n\n\n@api_view(['GET'])\ndef all_high_scores(request):\n queryset = HighScore.objects.order_by('-score')\n serializer = HighScoreSerializer(queryset, many=True)\n return Response(serializer.data)\n\n\n\nRead-write \nBaseSerializer\n classes\n\n\nTo create a read-write serializer we first need to implement a \n.to_internal_value()\n method. This method returns the validated values that will be used to construct the object instance, and may raise a \nserializers.ValidationError\n if the supplied data is in an incorrect format.\n\n\nOnce you've implemented \n.to_internal_value()\n, the basic validation API will be available on the serializer, and you will be able to use \n.is_valid()\n, \n.validated_data\n and \n.errors\n.\n\n\nIf you want to also support \n.save()\n you'll need to also implement either or both of the \n.create()\n and \n.update()\n methods.\n\n\nHere's a complete example of our previous \nHighScoreSerializer\n, that's been updated to support both read and write operations.\n\n\nclass HighScoreSerializer(serializers.BaseSerializer):\n def to_internal_value(self, data):\n score = data.get('score')\n player_name = data.get('player_name')\n\n # Perform the data validation.\n if not score:\n raise serializers.ValidationError({\n 'score': 'This field is required.'\n })\n if not player_name:\n raise serializers.ValidationError({\n 'player_name': 'This field is required.'\n })\n if len(player_name) > 10:\n raise serializers.ValidationError({\n 'player_name': 'May not be more than 10 characters.'\n })\n\n # Return the validated values. This will be available as\n # the `.validated_data` property.\n return {\n 'score': int(score),\n 'player_name': player_name\n }\n\n def to_representation(self, obj):\n return {\n 'score': obj.score,\n 'player_name': obj.player_name\n }\n\n def create(self, validated_data):\n return HighScore.objects.create(**validated_data)\n\n\n\nCreating new base classes\n\n\nThe \nBaseSerializer\n class is also useful if you want to implement new generic serializer classes for dealing with particular serialization styles, or for integrating with alternative storage backends.\n\n\nThe following class is an example of a generic serializer that can handle coercing arbitrary objects into primitive representations.\n\n\nclass ObjectSerializer(serializers.BaseSerializer):\n \"\"\"\n A read-only serializer that coerces arbitrary complex objects\n into primitive representations.\n \"\"\"\n def to_representation(self, obj):\n for attribute_name in dir(obj):\n attribute = getattr(obj, attribute_name)\n if attribute_name('_'):\n # Ignore private attributes.\n pass\n elif hasattr(attribute, '__call__'):\n # Ignore methods and other callables.\n pass\n elif isinstance(attribute, (str, int, bool, float, type(None))):\n # Primitive types can be passed through unmodified.\n output[attribute_name] = attribute\n elif isinstance(attribute, list):\n # Recursively deal with items in lists.\n output[attribute_name] = [\n self.to_representation(item) for item in attribute\n ]\n elif isinstance(attribute, dict):\n # Recursively deal with items in dictionaries.\n output[attribute_name] = {\n str(key): self.to_representation(value)\n for key, value in attribute.items()\n }\n else:\n # Force anything else to its string representation.\n output[attribute_name] = str(attribute)\n\n\n\n\n\nAdvanced serializer usage\n\n\nOverriding serialization and deserialization behavior\n\n\nIf you need to alter the serialization or deserialization behavior of a serializer class, you can do so by overriding the \n.to_representation()\n or \n.to_internal_value()\n methods.\n\n\nSome reasons this might be useful include...\n\n\n\n\nAdding new behavior for new serializer base classes.\n\n\nModifying the behavior slightly for an existing class.\n\n\nImproving serialization performance for a frequently accessed API endpoint that returns lots of data.\n\n\n\n\nThe signatures for these methods are as follows:\n\n\n.to_representation(self, obj)\n\n\nTakes the object instance that requires serialization, and should return a primitive representation. Typically this means returning a structure of built-in Python datatypes. The exact types that can be handled will depend on the render classes you have configured for your API.\n\n\nMay be overridden in order modify the representation style. For example:\n\n\ndef to_representation(self, instance):\n \"\"\"Convert `username` to lowercase.\"\"\"\n ret = super().to_representation(instance)\n ret['username'] = ret['username'].lower()\n return ret\n\n\n\n.to_internal_value(self, data)\n\n\nTakes the unvalidated incoming data as input and should return the validated data that will be made available as \nserializer.validated_data\n. The return value will also be passed to the \n.create()\n or \n.update()\n methods if \n.save()\n is called on the serializer class.\n\n\nIf any of the validation fails, then the method should raise a \nserializers.ValidationError(errors)\n. The \nerrors\n argument should be a dictionary mapping field names (or \nsettings.NON_FIELD_ERRORS_KEY\n) to a list of error messages. If you don't need to alter deserialization behavior and instead want to provide object-level validation, it's recommended that you instead override the \n.validate()\n method.\n\n\nThe \ndata\n argument passed to this method will normally be the value of \nrequest.data\n, so the datatype it provides will depend on the parser classes you have configured for your API.\n\n\nSerializer Inheritance\n\n\nSimilar to Django forms, you can extend and reuse serializers through inheritance. This allows you to declare a common set of fields or methods on a parent class that can then be used in a number of serializers. For example,\n\n\nclass MyBaseSerializer(Serializer):\n my_field = serializers.CharField()\n\n def validate_my_field(self, value):\n ...\n\nclass MySerializer(MyBaseSerializer):\n ...\n\n\n\nLike Django's \nModel\n and \nModelForm\n classes, the inner \nMeta\n class on serializers does not implicitly inherit from it's parents' inner \nMeta\n classes. If you want the \nMeta\n class to inherit from a parent class you must do so explicitly. For example:\n\n\nclass AccountSerializer(MyBaseSerializer):\n class Meta(MyBaseSerializer.Meta):\n model = Account\n\n\n\nTypically we would recommend \nnot\n using inheritance on inner Meta classes, but instead declaring all options explicitly.\n\n\nAdditionally, the following caveats apply to serializer inheritance:\n\n\n\n\nNormal Python name resolution rules apply. If you have multiple base classes that declare a \nMeta\n inner class, only the first one will be used. This means the child\u2019s \nMeta\n, if it exists, otherwise the \nMeta\n of the first parent, etc.\n\n\n\n\nIt\u2019s possible to declaratively remove a \nField\n inherited from a parent class by setting the name to be \nNone\n on the subclass.\n\n\nclass MyBaseSerializer(ModelSerializer):\n my_field = serializers.CharField()\n\nclass MySerializer(MyBaseSerializer):\n my_field = None\n\n\n\nHowever, you can only use this technique to opt out from a field defined declaratively by a parent class; it won\u2019t prevent the \nModelSerializer\n from generating a default field. To opt-out from default fields, see \nSpecifying which fields to include\n.\n\n\n\n\n\n\nDynamically modifying fields\n\n\nOnce a serializer has been initialized, the dictionary of fields that are set on the serializer may be accessed using the \n.fields\n attribute. Accessing and modifying this attribute allows you to dynamically modify the serializer.\n\n\nModifying the \nfields\n argument directly allows you to do interesting things such as changing the arguments on serializer fields at runtime, rather than at the point of declaring the serializer.\n\n\nExample\n\n\nFor example, if you wanted to be able to set which fields should be used by a serializer at the point of initializing it, you could create a serializer class like so:\n\n\nclass DynamicFieldsModelSerializer(serializers.ModelSerializer):\n \"\"\"\n A ModelSerializer that takes an additional `fields` argument that\n controls which fields should be displayed.\n \"\"\"\n\n def __init__(self, *args, **kwargs):\n # Don't pass the 'fields' arg up to the superclass\n fields = kwargs.pop('fields', None)\n\n # Instantiate the superclass normally\n super(DynamicFieldsModelSerializer, self).__init__(*args, **kwargs)\n\n if fields is not None:\n # Drop any fields that are not specified in the `fields` argument.\n allowed = set(fields)\n existing = set(self.fields)\n for field_name in existing - allowed:\n self.fields.pop(field_name)\n\n\n\nThis would then allow you to do the following:\n\n\n>>> class UserSerializer(DynamicFieldsModelSerializer):\n>>> class Meta:\n>>> model = User\n>>> fields = ('id', 'username', 'email')\n>>>\n>>> print UserSerializer(user)\n{'id': 2, 'username': 'jonwatts', 'email': 'jon@example.com'}\n>>>\n>>> print UserSerializer(user, fields=('id', 'email'))\n{'id': 2, 'email': 'jon@example.com'}\n\n\n\nCustomizing the default fields\n\n\nREST framework 2 provided an API to allow developers to override how a \nModelSerializer\n class would automatically generate the default set of fields.\n\n\nThis API included the \n.get_field()\n, \n.get_pk_field()\n and other methods.\n\n\nBecause the serializers have been fundamentally redesigned with 3.0 this API no longer exists. You can still modify the fields that get created but you'll need to refer to the source code, and be aware that if the changes you make are against private bits of API then they may be subject to change.\n\n\n\n\nThird party packages\n\n\nThe following third party packages are also available.\n\n\nDjango REST marshmallow\n\n\nThe \ndjango-rest-marshmallow\n package provides an alternative implementation for serializers, using the python \nmarshmallow\n library. It exposes the same API as the REST framework serializers, and can be used as a drop-in replacement in some use-cases.\n\n\nSerpy\n\n\nThe \nserpy\n package is an alternative implementation for serializers that is built for speed. \nSerpy\n serializes complex datatypes to simple native types. The native types can be easily converted to JSON or any other format needed.\n\n\nMongoengineModelSerializer\n\n\nThe \ndjango-rest-framework-mongoengine\n package provides a \nMongoEngineModelSerializer\n serializer class that supports using MongoDB as the storage layer for Django REST framework.\n\n\nGeoFeatureModelSerializer\n\n\nThe \ndjango-rest-framework-gis\n package provides a \nGeoFeatureModelSerializer\n serializer class that supports GeoJSON both for read and write operations.\n\n\nHStoreSerializer\n\n\nThe \ndjango-rest-framework-hstore\n package provides an \nHStoreSerializer\n to support \ndjango-hstore\n \nDictionaryField\n model field and its \nschema-mode\n feature.\n\n\nDynamic REST\n\n\nThe \ndynamic-rest\n package extends the ModelSerializer and ModelViewSet interfaces, adding API query parameters for filtering, sorting, and including / excluding all fields and relationships defined by your serializers.\n\n\nDynamic Fields Mixin\n\n\nThe \ndrf-dynamic-fields\n package provides a mixin to dynamically limit the fields per serializer to a subset specified by an URL parameter.\n\n\nDRF FlexFields\n\n\nThe \ndrf-flex-fields\n package extends the ModelSerializer and ModelViewSet to provide commonly used functionality for dynamically setting fields and expanding primitive fields to nested models, both from URL parameters and your serializer class definitions.\n\n\nSerializer Extensions\n\n\nThe \ndjango-rest-framework-serializer-extensions\n\npackage provides a collection of tools to DRY up your serializers, by allowing\nfields to be defined on a per-view/request basis. Fields can be whitelisted,\nblacklisted and child serializers can be optionally expanded.\n\n\nHTML JSON Forms\n\n\nThe \nhtml-json-forms\n package provides an algorithm and serializer for processing \n
    \n submissions per the (inactive) \nHTML JSON Form specification\n. The serializer facilitates processing of arbitrarily nested JSON structures within HTML. For example, \n\n will be interpreted as \n{\"items\": [{\"id\": \"5\"}]}\n.\n\n\nDRF-Base64\n\n\nDRF-Base64\n provides a set of field and model serializers that handles the upload of base64-encoded files.\n\n\nQueryFields\n\n\ndjangorestframework-queryfields\n allows API clients to specify which fields will be sent in the response via inclusion/exclusion query parameters.\n\n\nDRF Writable Nested\n\n\nThe \ndrf-writable-nested\n package provides writable nested model serializer which allows to create/update models with nested related data.", + "text": "Serializers\n\n\n\n\nExpanding the usefulness of the serializers is something that we would\nlike to address. However, it's not a trivial problem, and it\nwill take some serious design work.\n\n\n\u2014 Russell Keith-Magee, \nDjango users group\n\n\n\n\nSerializers allow complex data such as querysets and model instances to be converted to native Python datatypes that can then be easily rendered into \nJSON\n, \nXML\n or other content types. Serializers also provide deserialization, allowing parsed data to be converted back into complex types, after first validating the incoming data.\n\n\nThe serializers in REST framework work very similarly to Django's \nForm\n and \nModelForm\n classes. We provide a \nSerializer\n class which gives you a powerful, generic way to control the output of your responses, as well as a \nModelSerializer\n class which provides a useful shortcut for creating serializers that deal with model instances and querysets.\n\n\nDeclaring Serializers\n\n\nLet's start by creating a simple object we can use for example purposes:\n\n\nfrom datetime import datetime\n\nclass Comment(object):\n def __init__(self, email, content, created=None):\n self.email = email\n self.content = content\n self.created = created or datetime.now()\n\ncomment = Comment(email='leila@example.com', content='foo bar')\n\n\n\nWe'll declare a serializer that we can use to serialize and deserialize data that corresponds to \nComment\n objects.\n\n\nDeclaring a serializer looks very similar to declaring a form:\n\n\nfrom rest_framework import serializers\n\nclass CommentSerializer(serializers.Serializer):\n email = serializers.EmailField()\n content = serializers.CharField(max_length=200)\n created = serializers.DateTimeField()\n\n\n\nSerializing objects\n\n\nWe can now use \nCommentSerializer\n to serialize a comment, or list of comments. Again, using the \nSerializer\n class looks a lot like using a \nForm\n class.\n\n\nserializer = CommentSerializer(comment)\nserializer.data\n# {'email': 'leila@example.com', 'content': 'foo bar', 'created': '2016-01-27T15:17:10.375877'}\n\n\n\nAt this point we've translated the model instance into Python native datatypes. To finalise the serialization process we render the data into \njson\n.\n\n\nfrom rest_framework.renderers import JSONRenderer\n\njson = JSONRenderer().render(serializer.data)\njson\n# b'{\"email\":\"leila@example.com\",\"content\":\"foo bar\",\"created\":\"2016-01-27T15:17:10.375877\"}'\n\n\n\nDeserializing objects\n\n\nDeserialization is similar. First we parse a stream into Python native datatypes...\n\n\nimport io\nfrom rest_framework.parsers import JSONParser\n\nstream = io.BytesIO(json)\ndata = JSONParser().parse(stream)\n\n\n\n...then we restore those native datatypes into a dictionary of validated data.\n\n\nserializer = CommentSerializer(data=data)\nserializer.is_valid()\n# True\nserializer.validated_data\n# {'content': 'foo bar', 'email': 'leila@example.com', 'created': datetime.datetime(2012, 08, 22, 16, 20, 09, 822243)}\n\n\n\nSaving instances\n\n\nIf we want to be able to return complete object instances based on the validated data we need to implement one or both of the \n.create()\n and \n.update()\n methods. For example:\n\n\nclass CommentSerializer(serializers.Serializer):\n email = serializers.EmailField()\n content = serializers.CharField(max_length=200)\n created = serializers.DateTimeField()\n\n def create(self, validated_data):\n return Comment(**validated_data)\n\n def update(self, instance, validated_data):\n instance.email = validated_data.get('email', instance.email)\n instance.content = validated_data.get('content', instance.content)\n instance.created = validated_data.get('created', instance.created)\n return instance\n\n\n\nIf your object instances correspond to Django models you'll also want to ensure that these methods save the object to the database. For example, if \nComment\n was a Django model, the methods might look like this:\n\n\n def create(self, validated_data):\n return Comment.objects.create(**validated_data)\n\n def update(self, instance, validated_data):\n instance.email = validated_data.get('email', instance.email)\n instance.content = validated_data.get('content', instance.content)\n instance.created = validated_data.get('created', instance.created)\n instance.save()\n return instance\n\n\n\nNow when deserializing data, we can call \n.save()\n to return an object instance, based on the validated data.\n\n\ncomment = serializer.save()\n\n\n\nCalling \n.save()\n will either create a new instance, or update an existing instance, depending on if an existing instance was passed when instantiating the serializer class:\n\n\n# .save() will create a new instance.\nserializer = CommentSerializer(data=data)\n\n# .save() will update the existing `comment` instance.\nserializer = CommentSerializer(comment, data=data)\n\n\n\nBoth the \n.create()\n and \n.update()\n methods are optional. You can implement either neither, one, or both of them, depending on the use-case for your serializer class.\n\n\nPassing additional attributes to \n.save()\n\n\nSometimes you'll want your view code to be able to inject additional data at the point of saving the instance. This additional data might include information like the current user, the current time, or anything else that is not part of the request data.\n\n\nYou can do so by including additional keyword arguments when calling \n.save()\n. For example:\n\n\nserializer.save(owner=request.user)\n\n\n\nAny additional keyword arguments will be included in the \nvalidated_data\n argument when \n.create()\n or \n.update()\n are called.\n\n\nOverriding \n.save()\n directly.\n\n\nIn some cases the \n.create()\n and \n.update()\n method names may not be meaningful. For example, in a contact form we may not be creating new instances, but instead sending an email or other message.\n\n\nIn these cases you might instead choose to override \n.save()\n directly, as being more readable and meaningful.\n\n\nFor example:\n\n\nclass ContactForm(serializers.Serializer):\n email = serializers.EmailField()\n message = serializers.CharField()\n\n def save(self):\n email = self.validated_data['email']\n message = self.validated_data['message']\n send_email(from=email, message=message)\n\n\n\nNote that in the case above we're now having to access the serializer \n.validated_data\n property directly.\n\n\nValidation\n\n\nWhen deserializing data, you always need to call \nis_valid()\n before attempting to access the validated data, or save an object instance. If any validation errors occur, the \n.errors\n property will contain a dictionary representing the resulting error messages. For example:\n\n\nserializer = CommentSerializer(data={'email': 'foobar', 'content': 'baz'})\nserializer.is_valid()\n# False\nserializer.errors\n# {'email': [u'Enter a valid e-mail address.'], 'created': [u'This field is required.']}\n\n\n\nEach key in the dictionary will be the field name, and the values will be lists of strings of any error messages corresponding to that field. The \nnon_field_errors\n key may also be present, and will list any general validation errors. The name of the \nnon_field_errors\n key may be customized using the \nNON_FIELD_ERRORS_KEY\n REST framework setting.\n\n\nWhen deserializing a list of items, errors will be returned as a list of dictionaries representing each of the deserialized items.\n\n\nRaising an exception on invalid data\n\n\nThe \n.is_valid()\n method takes an optional \nraise_exception\n flag that will cause it to raise a \nserializers.ValidationError\n exception if there are validation errors.\n\n\nThese exceptions are automatically dealt with by the default exception handler that REST framework provides, and will return \nHTTP 400 Bad Request\n responses by default.\n\n\n# Return a 400 response if the data was invalid.\nserializer.is_valid(raise_exception=True)\n\n\n\nField-level validation\n\n\nYou can specify custom field-level validation by adding \n.validate_\n methods to your \nSerializer\n subclass. These are similar to the \n.clean_\n methods on Django forms.\n\n\nThese methods take a single argument, which is the field value that requires validation.\n\n\nYour \nvalidate_\n methods should return the validated value or raise a \nserializers.ValidationError\n. For example:\n\n\nfrom rest_framework import serializers\n\nclass BlogPostSerializer(serializers.Serializer):\n title = serializers.CharField(max_length=100)\n content = serializers.CharField()\n\n def validate_title(self, value):\n \"\"\"\n Check that the blog post is about Django.\n \"\"\"\n if 'django' not in value.lower():\n raise serializers.ValidationError(\"Blog post is not about Django\")\n return value\n\n\n\n\n\nNote:\n If your \n\n is declared on your serializer with the parameter \nrequired=False\n then this validation step will not take place if the field is not included.\n\n\n\n\nObject-level validation\n\n\nTo do any other validation that requires access to multiple fields, add a method called \n.validate()\n to your \nSerializer\n subclass. This method takes a single argument, which is a dictionary of field values. It should raise a \nserializers.ValidationError\n if necessary, or just return the validated values. For example:\n\n\nfrom rest_framework import serializers\n\nclass EventSerializer(serializers.Serializer):\n description = serializers.CharField(max_length=100)\n start = serializers.DateTimeField()\n finish = serializers.DateTimeField()\n\n def validate(self, data):\n \"\"\"\n Check that start is before finish.\n \"\"\"\n if data['start'] > data['finish']:\n raise serializers.ValidationError(\"finish must occur after start\")\n return data\n\n\n\nValidators\n\n\nIndividual fields on a serializer can include validators, by declaring them on the field instance, for example:\n\n\ndef multiple_of_ten(value):\n if value % 10 != 0:\n raise serializers.ValidationError('Not a multiple of ten')\n\nclass GameRecord(serializers.Serializer):\n score = IntegerField(validators=[multiple_of_ten])\n ...\n\n\n\nSerializer classes can also include reusable validators that are applied to the complete set of field data. These validators are included by declaring them on an inner \nMeta\n class, like so:\n\n\nclass EventSerializer(serializers.Serializer):\n name = serializers.CharField()\n room_number = serializers.IntegerField(choices=[101, 102, 103, 201])\n date = serializers.DateField()\n\n class Meta:\n # Each room only has one event per day.\n validators = UniqueTogetherValidator(\n queryset=Event.objects.all(),\n fields=['room_number', 'date']\n )\n\n\n\nFor more information see the \nvalidators documentation\n.\n\n\nAccessing the initial data and instance\n\n\nWhen passing an initial object or queryset to a serializer instance, the object will be made available as \n.instance\n. If no initial object is passed then the \n.instance\n attribute will be \nNone\n.\n\n\nWhen passing data to a serializer instance, the unmodified data will be made available as \n.initial_data\n. If the data keyword argument is not passed then the \n.initial_data\n attribute will not exist.\n\n\nPartial updates\n\n\nBy default, serializers must be passed values for all required fields or they will raise validation errors. You can use the \npartial\n argument in order to allow partial updates.\n\n\n# Update `comment` with partial data\nserializer = CommentSerializer(comment, data={'content': u'foo bar'}, partial=True)\n\n\n\nDealing with nested objects\n\n\nThe previous examples are fine for dealing with objects that only have simple datatypes, but sometimes we also need to be able to represent more complex objects, where some of the attributes of an object might not be simple datatypes such as strings, dates or integers.\n\n\nThe \nSerializer\n class is itself a type of \nField\n, and can be used to represent relationships where one object type is nested inside another.\n\n\nclass UserSerializer(serializers.Serializer):\n email = serializers.EmailField()\n username = serializers.CharField(max_length=100)\n\nclass CommentSerializer(serializers.Serializer):\n user = UserSerializer()\n content = serializers.CharField(max_length=200)\n created = serializers.DateTimeField()\n\n\n\nIf a nested representation may optionally accept the \nNone\n value you should pass the \nrequired=False\n flag to the nested serializer.\n\n\nclass CommentSerializer(serializers.Serializer):\n user = UserSerializer(required=False) # May be an anonymous user.\n content = serializers.CharField(max_length=200)\n created = serializers.DateTimeField()\n\n\n\nSimilarly if a nested representation should be a list of items, you should pass the \nmany=True\n flag to the nested serialized.\n\n\nclass CommentSerializer(serializers.Serializer):\n user = UserSerializer(required=False)\n edits = EditItemSerializer(many=True) # A nested list of 'edit' items.\n content = serializers.CharField(max_length=200)\n created = serializers.DateTimeField()\n\n\n\nWritable nested representations\n\n\nWhen dealing with nested representations that support deserializing the data, any errors with nested objects will be nested under the field name of the nested object.\n\n\nserializer = CommentSerializer(data={'user': {'email': 'foobar', 'username': 'doe'}, 'content': 'baz'})\nserializer.is_valid()\n# False\nserializer.errors\n# {'user': {'email': [u'Enter a valid e-mail address.']}, 'created': [u'This field is required.']}\n\n\n\nSimilarly, the \n.validated_data\n property will include nested data structures.\n\n\nWriting \n.create()\n methods for nested representations\n\n\nIf you're supporting writable nested representations you'll need to write \n.create()\n or \n.update()\n methods that handle saving multiple objects.\n\n\nThe following example demonstrates how you might handle creating a user with a nested profile object.\n\n\nclass UserSerializer(serializers.ModelSerializer):\n profile = ProfileSerializer()\n\n class Meta:\n model = User\n fields = ('username', 'email', 'profile')\n\n def create(self, validated_data):\n profile_data = validated_data.pop('profile')\n user = User.objects.create(**validated_data)\n Profile.objects.create(user=user, **profile_data)\n return user\n\n\n\nWriting \n.update()\n methods for nested representations\n\n\nFor updates you'll want to think carefully about how to handle updates to relationships. For example if the data for the relationship is \nNone\n, or not provided, which of the following should occur?\n\n\n\n\nSet the relationship to \nNULL\n in the database.\n\n\nDelete the associated instance.\n\n\nIgnore the data and leave the instance as it is.\n\n\nRaise a validation error.\n\n\n\n\nHere's an example for an \n.update()\n method on our previous \nUserSerializer\n class.\n\n\n def update(self, instance, validated_data):\n profile_data = validated_data.pop('profile')\n # Unless the application properly enforces that this field is\n # always set, the follow could raise a `DoesNotExist`, which\n # would need to be handled.\n profile = instance.profile\n\n instance.username = validated_data.get('username', instance.username)\n instance.email = validated_data.get('email', instance.email)\n instance.save()\n\n profile.is_premium_member = profile_data.get(\n 'is_premium_member',\n profile.is_premium_member\n )\n profile.has_support_contract = profile_data.get(\n 'has_support_contract',\n profile.has_support_contract\n )\n profile.save()\n\n return instance\n\n\n\nBecause the behavior of nested creates and updates can be ambiguous, and may require complex dependencies between related models, REST framework 3 requires you to always write these methods explicitly. The default \nModelSerializer\n \n.create()\n and \n.update()\n methods do not include support for writable nested representations.\n\n\nThere are however, third-party packages available such as \nDRF Writable Nested\n that support automatic writable nested representations.\n\n\nHandling saving related instances in model manager classes\n\n\nAn alternative to saving multiple related instances in the serializer is to write custom model manager classes that handle creating the correct instances.\n\n\nFor example, suppose we wanted to ensure that \nUser\n instances and \nProfile\n instances are always created together as a pair. We might write a custom manager class that looks something like this:\n\n\nclass UserManager(models.Manager):\n ...\n\n def create(self, username, email, is_premium_member=False, has_support_contract=False):\n user = User(username=username, email=email)\n user.save()\n profile = Profile(\n user=user,\n is_premium_member=is_premium_member,\n has_support_contract=has_support_contract\n )\n profile.save()\n return user\n\n\n\nThis manager class now more nicely encapsulates that user instances and profile instances are always created at the same time. Our \n.create()\n method on the serializer class can now be re-written to use the new manager method.\n\n\ndef create(self, validated_data):\n return User.objects.create(\n username=validated_data['username'],\n email=validated_data['email']\n is_premium_member=validated_data['profile']['is_premium_member']\n has_support_contract=validated_data['profile']['has_support_contract']\n )\n\n\n\nFor more details on this approach see the Django documentation on \nmodel managers\n, and \nthis blogpost on using model and manager classes\n.\n\n\nDealing with multiple objects\n\n\nThe \nSerializer\n class can also handle serializing or deserializing lists of objects.\n\n\nSerializing multiple objects\n\n\nTo serialize a queryset or list of objects instead of a single object instance, you should pass the \nmany=True\n flag when instantiating the serializer. You can then pass a queryset or list of objects to be serialized.\n\n\nqueryset = Book.objects.all()\nserializer = BookSerializer(queryset, many=True)\nserializer.data\n# [\n# {'id': 0, 'title': 'The electric kool-aid acid test', 'author': 'Tom Wolfe'},\n# {'id': 1, 'title': 'If this is a man', 'author': 'Primo Levi'},\n# {'id': 2, 'title': 'The wind-up bird chronicle', 'author': 'Haruki Murakami'}\n# ]\n\n\n\nDeserializing multiple objects\n\n\nThe default behavior for deserializing multiple objects is to support multiple object creation, but not support multiple object updates. For more information on how to support or customize either of these cases, see the \nListSerializer\n documentation below.\n\n\nIncluding extra context\n\n\nThere are some cases where you need to provide extra context to the serializer in addition to the object being serialized. One common case is if you're using a serializer that includes hyperlinked relations, which requires the serializer to have access to the current request so that it can properly generate fully qualified URLs.\n\n\nYou can provide arbitrary additional context by passing a \ncontext\n argument when instantiating the serializer. For example:\n\n\nserializer = AccountSerializer(account, context={'request': request})\nserializer.data\n# {'id': 6, 'owner': u'denvercoder9', 'created': datetime.datetime(2013, 2, 12, 09, 44, 56, 678870), 'details': 'http://example.com/accounts/6/details'}\n\n\n\nThe context dictionary can be used within any serializer field logic, such as a custom \n.to_representation()\n method, by accessing the \nself.context\n attribute.\n\n\n\n\nModelSerializer\n\n\nOften you'll want serializer classes that map closely to Django model definitions.\n\n\nThe \nModelSerializer\n class provides a shortcut that lets you automatically create a \nSerializer\n class with fields that correspond to the Model fields.\n\n\nThe \nModelSerializer\n class is the same as a regular \nSerializer\n class, except that\n:\n\n\n\n\nIt will automatically generate a set of fields for you, based on the model.\n\n\nIt will automatically generate validators for the serializer, such as unique_together validators.\n\n\nIt includes simple default implementations of \n.create()\n and \n.update()\n.\n\n\n\n\nDeclaring a \nModelSerializer\n looks like this:\n\n\nclass AccountSerializer(serializers.ModelSerializer):\n class Meta:\n model = Account\n fields = ('id', 'account_name', 'users', 'created')\n\n\n\nBy default, all the model fields on the class will be mapped to a corresponding serializer fields.\n\n\nAny relationships such as foreign keys on the model will be mapped to \nPrimaryKeyRelatedField\n. Reverse relationships are not included by default unless explicitly included as specified in the \nserializer relations\n documentation.\n\n\nInspecting a \nModelSerializer\n\n\nSerializer classes generate helpful verbose representation strings, that allow you to fully inspect the state of their fields. This is particularly useful when working with \nModelSerializers\n where you want to determine what set of fields and validators are being automatically created for you.\n\n\nTo do so, open the Django shell, using \npython manage.py shell\n, then import the serializer class, instantiate it, and print the object representation\u2026\n\n\n>>> from myapp.serializers import AccountSerializer\n>>> serializer = AccountSerializer()\n>>> print(repr(serializer))\nAccountSerializer():\n id = IntegerField(label='ID', read_only=True)\n name = CharField(allow_blank=True, max_length=100, required=False)\n owner = PrimaryKeyRelatedField(queryset=User.objects.all())\n\n\n\nSpecifying which fields to include\n\n\nIf you only want a subset of the default fields to be used in a model serializer, you can do so using \nfields\n or \nexclude\n options, just as you would with a \nModelForm\n. It is strongly recommended that you explicitly set all fields that should be serialized using the \nfields\n attribute. This will make it less likely to result in unintentionally exposing data when your models change.\n\n\nFor example:\n\n\nclass AccountSerializer(serializers.ModelSerializer):\n class Meta:\n model = Account\n fields = ('id', 'account_name', 'users', 'created')\n\n\n\nYou can also set the \nfields\n attribute to the special value \n'__all__'\n to indicate that all fields in the model should be used.\n\n\nFor example:\n\n\nclass AccountSerializer(serializers.ModelSerializer):\n class Meta:\n model = Account\n fields = '__all__'\n\n\n\nYou can set the \nexclude\n attribute to a list of fields to be excluded from the serializer.\n\n\nFor example:\n\n\nclass AccountSerializer(serializers.ModelSerializer):\n class Meta:\n model = Account\n exclude = ('users',)\n\n\n\nIn the example above, if the \nAccount\n model had 3 fields \naccount_name\n, \nusers\n, and \ncreated\n, this will result in the fields \naccount_name\n and \ncreated\n to be serialized.\n\n\nThe names in the \nfields\n and \nexclude\n attributes will normally map to model fields on the model class.\n\n\nAlternatively names in the \nfields\n options can map to properties or methods which take no arguments that exist on the model class.\n\n\nSince version 3.3.0, it is \nmandatory\n to provide one of the attributes \nfields\n or \nexclude\n.\n\n\nSpecifying nested serialization\n\n\nThe default \nModelSerializer\n uses primary keys for relationships, but you can also easily generate nested representations using the \ndepth\n option:\n\n\nclass AccountSerializer(serializers.ModelSerializer):\n class Meta:\n model = Account\n fields = ('id', 'account_name', 'users', 'created')\n depth = 1\n\n\n\nThe \ndepth\n option should be set to an integer value that indicates the depth of relationships that should be traversed before reverting to a flat representation.\n\n\nIf you want to customize the way the serialization is done you'll need to define the field yourself.\n\n\nSpecifying fields explicitly\n\n\nYou can add extra fields to a \nModelSerializer\n or override the default fields by declaring fields on the class, just as you would for a \nSerializer\n class.\n\n\nclass AccountSerializer(serializers.ModelSerializer):\n url = serializers.CharField(source='get_absolute_url', read_only=True)\n groups = serializers.PrimaryKeyRelatedField(many=True)\n\n class Meta:\n model = Account\n\n\n\nExtra fields can correspond to any property or callable on the model.\n\n\nSpecifying read only fields\n\n\nYou may wish to specify multiple fields as read-only. Instead of adding each field explicitly with the \nread_only=True\n attribute, you may use the shortcut Meta option, \nread_only_fields\n.\n\n\nThis option should be a list or tuple of field names, and is declared as follows:\n\n\nclass AccountSerializer(serializers.ModelSerializer):\n class Meta:\n model = Account\n fields = ('id', 'account_name', 'users', 'created')\n read_only_fields = ('account_name',)\n\n\n\nModel fields which have \neditable=False\n set, and \nAutoField\n fields will be set to read-only by default, and do not need to be added to the \nread_only_fields\n option.\n\n\n\n\nNote\n: There is a special-case where a read-only field is part of a \nunique_together\n constraint at the model level. In this case the field is required by the serializer class in order to validate the constraint, but should also not be editable by the user.\n\n\nThe right way to deal with this is to specify the field explicitly on the serializer, providing both the \nread_only=True\n and \ndefault=\u2026\n keyword arguments.\n\n\nOne example of this is a read-only relation to the currently authenticated \nUser\n which is \nunique_together\n with another identifier. In this case you would declare the user field like so:\n\n\nuser = serializers.PrimaryKeyRelatedField(read_only=True, default=serializers.CurrentUserDefault())\n\n\n\nPlease review the \nValidators Documentation\n for details on the \nUniqueTogetherValidator\n and \nCurrentUserDefault\n classes.\n\n\n\n\nAdditional keyword arguments\n\n\nThere is also a shortcut allowing you to specify arbitrary additional keyword arguments on fields, using the \nextra_kwargs\n option. As in the case of \nread_only_fields\n, this means you do not need to explicitly declare the field on the serializer.\n\n\nThis option is a dictionary, mapping field names to a dictionary of keyword arguments. For example:\n\n\nclass CreateUserSerializer(serializers.ModelSerializer):\n class Meta:\n model = User\n fields = ('email', 'username', 'password')\n extra_kwargs = {'password': {'write_only': True}}\n\n def create(self, validated_data):\n user = User(\n email=validated_data['email'],\n username=validated_data['username']\n )\n user.set_password(validated_data['password'])\n user.save()\n return user\n\n\n\nRelational fields\n\n\nWhen serializing model instances, there are a number of different ways you might choose to represent relationships. The default representation for \nModelSerializer\n is to use the primary keys of the related instances.\n\n\nAlternative representations include serializing using hyperlinks, serializing complete nested representations, or serializing with a custom representation.\n\n\nFor full details see the \nserializer relations\n documentation.\n\n\nCustomizing field mappings\n\n\nThe ModelSerializer class also exposes an API that you can override in order to alter how serializer fields are automatically determined when instantiating the serializer.\n\n\nNormally if a \nModelSerializer\n does not generate the fields you need by default then you should either add them to the class explicitly, or simply use a regular \nSerializer\n class instead. However in some cases you may want to create a new base class that defines how the serializer fields are created for any given model.\n\n\n.serializer_field_mapping\n\n\nA mapping of Django model classes to REST framework serializer classes. You can override this mapping to alter the default serializer classes that should be used for each model class.\n\n\n.serializer_related_field\n\n\nThis property should be the serializer field class, that is used for relational fields by default.\n\n\nFor \nModelSerializer\n this defaults to \nPrimaryKeyRelatedField\n.\n\n\nFor \nHyperlinkedModelSerializer\n this defaults to \nserializers.HyperlinkedRelatedField\n.\n\n\nserializer_url_field\n\n\nThe serializer field class that should be used for any \nurl\n field on the serializer.\n\n\nDefaults to \nserializers.HyperlinkedIdentityField\n\n\nserializer_choice_field\n\n\nThe serializer field class that should be used for any choice fields on the serializer.\n\n\nDefaults to \nserializers.ChoiceField\n\n\nThe field_class and field_kwargs API\n\n\nThe following methods are called to determine the class and keyword arguments for each field that should be automatically included on the serializer. Each of these methods should return a two tuple of \n(field_class, field_kwargs)\n.\n\n\n.build_standard_field(self, field_name, model_field)\n\n\nCalled to generate a serializer field that maps to a standard model field.\n\n\nThe default implementation returns a serializer class based on the \nserializer_field_mapping\n attribute.\n\n\n.build_relational_field(self, field_name, relation_info)\n\n\nCalled to generate a serializer field that maps to a relational model field.\n\n\nThe default implementation returns a serializer class based on the \nserializer_relational_field\n attribute.\n\n\nThe \nrelation_info\n argument is a named tuple, that contains \nmodel_field\n, \nrelated_model\n, \nto_many\n and \nhas_through_model\n properties.\n\n\n.build_nested_field(self, field_name, relation_info, nested_depth)\n\n\nCalled to generate a serializer field that maps to a relational model field, when the \ndepth\n option has been set.\n\n\nThe default implementation dynamically creates a nested serializer class based on either \nModelSerializer\n or \nHyperlinkedModelSerializer\n.\n\n\nThe \nnested_depth\n will be the value of the \ndepth\n option, minus one.\n\n\nThe \nrelation_info\n argument is a named tuple, that contains \nmodel_field\n, \nrelated_model\n, \nto_many\n and \nhas_through_model\n properties.\n\n\n.build_property_field(self, field_name, model_class)\n\n\nCalled to generate a serializer field that maps to a property or zero-argument method on the model class.\n\n\nThe default implementation returns a \nReadOnlyField\n class.\n\n\n.build_url_field(self, field_name, model_class)\n\n\nCalled to generate a serializer field for the serializer's own \nurl\n field. The default implementation returns a \nHyperlinkedIdentityField\n class.\n\n\n.build_unknown_field(self, field_name, model_class)\n\n\nCalled when the field name did not map to any model field or model property.\nThe default implementation raises an error, although subclasses may customize this behavior.\n\n\n\n\nHyperlinkedModelSerializer\n\n\nThe \nHyperlinkedModelSerializer\n class is similar to the \nModelSerializer\n class except that it uses hyperlinks to represent relationships, rather than primary keys.\n\n\nBy default the serializer will include a \nurl\n field instead of a primary key field.\n\n\nThe url field will be represented using a \nHyperlinkedIdentityField\n serializer field, and any relationships on the model will be represented using a \nHyperlinkedRelatedField\n serializer field.\n\n\nYou can explicitly include the primary key by adding it to the \nfields\n option, for example:\n\n\nclass AccountSerializer(serializers.HyperlinkedModelSerializer):\n class Meta:\n model = Account\n fields = ('url', 'id', 'account_name', 'users', 'created')\n\n\n\nAbsolute and relative URLs\n\n\nWhen instantiating a \nHyperlinkedModelSerializer\n you must include the current\n\nrequest\n in the serializer context, for example:\n\n\nserializer = AccountSerializer(queryset, context={'request': request})\n\n\n\nDoing so will ensure that the hyperlinks can include an appropriate hostname,\nso that the resulting representation uses fully qualified URLs, such as:\n\n\nhttp://api.example.com/accounts/1/\n\n\n\nRather than relative URLs, such as:\n\n\n/accounts/1/\n\n\n\nIf you \ndo\n want to use relative URLs, you should explicitly pass \n{'request': None}\n\nin the serializer context.\n\n\nHow hyperlinked views are determined\n\n\nThere needs to be a way of determining which views should be used for hyperlinking to model instances.\n\n\nBy default hyperlinks are expected to correspond to a view name that matches the style \n'{model_name}-detail'\n, and looks up the instance by a \npk\n keyword argument.\n\n\nYou can override a URL field view name and lookup field by using either, or both of, the \nview_name\n and \nlookup_field\n options in the \nextra_kwargs\n setting, like so:\n\n\nclass AccountSerializer(serializers.HyperlinkedModelSerializer):\n class Meta:\n model = Account\n fields = ('account_url', 'account_name', 'users', 'created')\n extra_kwargs = {\n 'url': {'view_name': 'accounts', 'lookup_field': 'account_name'},\n 'users': {'lookup_field': 'username'}\n }\n\n\n\nAlternatively you can set the fields on the serializer explicitly. For example:\n\n\nclass AccountSerializer(serializers.HyperlinkedModelSerializer):\n url = serializers.HyperlinkedIdentityField(\n view_name='accounts',\n lookup_field='slug'\n )\n users = serializers.HyperlinkedRelatedField(\n view_name='user-detail',\n lookup_field='username',\n many=True,\n read_only=True\n )\n\n class Meta:\n model = Account\n fields = ('url', 'account_name', 'users', 'created')\n\n\n\n\n\nTip\n: Properly matching together hyperlinked representations and your URL conf can sometimes be a bit fiddly. Printing the \nrepr\n of a \nHyperlinkedModelSerializer\n instance is a particularly useful way to inspect exactly which view names and lookup fields the relationships are expected to map too.\n\n\n\n\nChanging the URL field name\n\n\nThe name of the URL field defaults to 'url'. You can override this globally, by using the \nURL_FIELD_NAME\n setting.\n\n\n\n\nListSerializer\n\n\nThe \nListSerializer\n class provides the behavior for serializing and validating multiple objects at once. You won't \ntypically\n need to use \nListSerializer\n directly, but should instead simply pass \nmany=True\n when instantiating a serializer.\n\n\nWhen a serializer is instantiated and \nmany=True\n is passed, a \nListSerializer\n instance will be created. The serializer class then becomes a child of the parent \nListSerializer\n\n\nThe following argument can also be passed to a \nListSerializer\n field or a serializer that is passed \nmany=True\n:\n\n\nallow_empty\n\n\nThis is \nTrue\n by default, but can be set to \nFalse\n if you want to disallow empty lists as valid input.\n\n\nCustomizing \nListSerializer\n behavior\n\n\nThere \nare\n a few use cases when you might want to customize the \nListSerializer\n behavior. For example:\n\n\n\n\nYou want to provide particular validation of the lists, such as checking that one element does not conflict with another element in a list.\n\n\nYou want to customize the create or update behavior of multiple objects.\n\n\n\n\nFor these cases you can modify the class that is used when \nmany=True\n is passed, by using the \nlist_serializer_class\n option on the serializer \nMeta\n class.\n\n\nFor example:\n\n\nclass CustomListSerializer(serializers.ListSerializer):\n ...\n\nclass CustomSerializer(serializers.Serializer):\n ...\n class Meta:\n list_serializer_class = CustomListSerializer\n\n\n\nCustomizing multiple create\n\n\nThe default implementation for multiple object creation is to simply call \n.create()\n for each item in the list. If you want to customize this behavior, you'll need to customize the \n.create()\n method on \nListSerializer\n class that is used when \nmany=True\n is passed.\n\n\nFor example:\n\n\nclass BookListSerializer(serializers.ListSerializer):\n def create(self, validated_data):\n books = [Book(**item) for item in validated_data]\n return Book.objects.bulk_create(books)\n\nclass BookSerializer(serializers.Serializer):\n ...\n class Meta:\n list_serializer_class = BookListSerializer\n\n\n\nCustomizing multiple update\n\n\nBy default the \nListSerializer\n class does not support multiple updates. This is because the behavior that should be expected for insertions and deletions is ambiguous.\n\n\nTo support multiple updates you'll need to do so explicitly. When writing your multiple update code make sure to keep the following in mind:\n\n\n\n\nHow do you determine which instance should be updated for each item in the list of data?\n\n\nHow should insertions be handled? Are they invalid, or do they create new objects?\n\n\nHow should removals be handled? Do they imply object deletion, or removing a relationship? Should they be silently ignored, or are they invalid?\n\n\nHow should ordering be handled? Does changing the position of two items imply any state change or is it ignored?\n\n\n\n\nYou will need to add an explicit \nid\n field to the instance serializer. The default implicitly-generated \nid\n field is marked as \nread_only\n. This causes it to be removed on updates. Once you declare it explicitly, it will be available in the list serializer's \nupdate\n method.\n\n\nHere's an example of how you might choose to implement multiple updates:\n\n\nclass BookListSerializer(serializers.ListSerializer):\n def update(self, instance, validated_data):\n # Maps for id->instance and id->data item.\n book_mapping = {book.id: book for book in instance}\n data_mapping = {item['id']: item for item in validated_data}\n\n # Perform creations and updates.\n ret = []\n for book_id, data in data_mapping.items():\n book = book_mapping.get(book_id, None)\n if book is None:\n ret.append(self.child.create(data))\n else:\n ret.append(self.child.update(book, data))\n\n # Perform deletions.\n for book_id, book in book_mapping.items():\n if book_id not in data_mapping:\n book.delete()\n\n return ret\n\nclass BookSerializer(serializers.Serializer):\n # We need to identify elements in the list using their primary key,\n # so use a writable field here, rather than the default which would be read-only.\n id = serializers.IntegerField()\n ...\n\n class Meta:\n list_serializer_class = BookListSerializer\n\n\n\nIt is possible that a third party package may be included alongside the 3.1 release that provides some automatic support for multiple update operations, similar to the \nallow_add_remove\n behavior that was present in REST framework 2.\n\n\nCustomizing ListSerializer initialization\n\n\nWhen a serializer with \nmany=True\n is instantiated, we need to determine which arguments and keyword arguments should be passed to the \n.__init__()\n method for both the child \nSerializer\n class, and for the parent \nListSerializer\n class.\n\n\nThe default implementation is to pass all arguments to both classes, except for \nvalidators\n, and any custom keyword arguments, both of which are assumed to be intended for the child serializer class.\n\n\nOccasionally you might need to explicitly specify how the child and parent classes should be instantiated when \nmany=True\n is passed. You can do so by using the \nmany_init\n class method.\n\n\n @classmethod\n def many_init(cls, *args, **kwargs):\n # Instantiate the child serializer.\n kwargs['child'] = cls()\n # Instantiate the parent list serializer.\n return CustomListSerializer(*args, **kwargs)\n\n\n\n\n\nBaseSerializer\n\n\nBaseSerializer\n class that can be used to easily support alternative serialization and deserialization styles.\n\n\nThis class implements the same basic API as the \nSerializer\n class:\n\n\n\n\n.data\n - Returns the outgoing primitive representation.\n\n\n.is_valid()\n - Deserializes and validates incoming data.\n\n\n.validated_data\n - Returns the validated incoming data.\n\n\n.errors\n - Returns any errors during validation.\n\n\n.save()\n - Persists the validated data into an object instance.\n\n\n\n\nThere are four methods that can be overridden, depending on what functionality you want the serializer class to support:\n\n\n\n\n.to_representation()\n - Override this to support serialization, for read operations.\n\n\n.to_internal_value()\n - Override this to support deserialization, for write operations.\n\n\n.create()\n and \n.update()\n - Override either or both of these to support saving instances.\n\n\n\n\nBecause this class provides the same interface as the \nSerializer\n class, you can use it with the existing generic class-based views exactly as you would for a regular \nSerializer\n or \nModelSerializer\n.\n\n\nThe only difference you'll notice when doing so is the \nBaseSerializer\n classes will not generate HTML forms in the browsable API. This is because the data they return does not include all the field information that would allow each field to be rendered into a suitable HTML input.\n\n\nRead-only \nBaseSerializer\n classes\n\n\nTo implement a read-only serializer using the \nBaseSerializer\n class, we just need to override the \n.to_representation()\n method. Let's take a look at an example using a simple Django model:\n\n\nclass HighScore(models.Model):\n created = models.DateTimeField(auto_now_add=True)\n player_name = models.CharField(max_length=10)\n score = models.IntegerField()\n\n\n\nIt's simple to create a read-only serializer for converting \nHighScore\n instances into primitive data types.\n\n\nclass HighScoreSerializer(serializers.BaseSerializer):\n def to_representation(self, obj):\n return {\n 'score': obj.score,\n 'player_name': obj.player_name\n }\n\n\n\nWe can now use this class to serialize single \nHighScore\n instances:\n\n\n@api_view(['GET'])\ndef high_score(request, pk):\n instance = HighScore.objects.get(pk=pk)\n serializer = HighScoreSerializer(instance)\n return Response(serializer.data)\n\n\n\nOr use it to serialize multiple instances:\n\n\n@api_view(['GET'])\ndef all_high_scores(request):\n queryset = HighScore.objects.order_by('-score')\n serializer = HighScoreSerializer(queryset, many=True)\n return Response(serializer.data)\n\n\n\nRead-write \nBaseSerializer\n classes\n\n\nTo create a read-write serializer we first need to implement a \n.to_internal_value()\n method. This method returns the validated values that will be used to construct the object instance, and may raise a \nserializers.ValidationError\n if the supplied data is in an incorrect format.\n\n\nOnce you've implemented \n.to_internal_value()\n, the basic validation API will be available on the serializer, and you will be able to use \n.is_valid()\n, \n.validated_data\n and \n.errors\n.\n\n\nIf you want to also support \n.save()\n you'll need to also implement either or both of the \n.create()\n and \n.update()\n methods.\n\n\nHere's a complete example of our previous \nHighScoreSerializer\n, that's been updated to support both read and write operations.\n\n\nclass HighScoreSerializer(serializers.BaseSerializer):\n def to_internal_value(self, data):\n score = data.get('score')\n player_name = data.get('player_name')\n\n # Perform the data validation.\n if not score:\n raise serializers.ValidationError({\n 'score': 'This field is required.'\n })\n if not player_name:\n raise serializers.ValidationError({\n 'player_name': 'This field is required.'\n })\n if len(player_name) > 10:\n raise serializers.ValidationError({\n 'player_name': 'May not be more than 10 characters.'\n })\n\n # Return the validated values. This will be available as\n # the `.validated_data` property.\n return {\n 'score': int(score),\n 'player_name': player_name\n }\n\n def to_representation(self, obj):\n return {\n 'score': obj.score,\n 'player_name': obj.player_name\n }\n\n def create(self, validated_data):\n return HighScore.objects.create(**validated_data)\n\n\n\nCreating new base classes\n\n\nThe \nBaseSerializer\n class is also useful if you want to implement new generic serializer classes for dealing with particular serialization styles, or for integrating with alternative storage backends.\n\n\nThe following class is an example of a generic serializer that can handle coercing arbitrary objects into primitive representations.\n\n\nclass ObjectSerializer(serializers.BaseSerializer):\n \"\"\"\n A read-only serializer that coerces arbitrary complex objects\n into primitive representations.\n \"\"\"\n def to_representation(self, obj):\n for attribute_name in dir(obj):\n attribute = getattr(obj, attribute_name)\n if attribute_name('_'):\n # Ignore private attributes.\n pass\n elif hasattr(attribute, '__call__'):\n # Ignore methods and other callables.\n pass\n elif isinstance(attribute, (str, int, bool, float, type(None))):\n # Primitive types can be passed through unmodified.\n output[attribute_name] = attribute\n elif isinstance(attribute, list):\n # Recursively deal with items in lists.\n output[attribute_name] = [\n self.to_representation(item) for item in attribute\n ]\n elif isinstance(attribute, dict):\n # Recursively deal with items in dictionaries.\n output[attribute_name] = {\n str(key): self.to_representation(value)\n for key, value in attribute.items()\n }\n else:\n # Force anything else to its string representation.\n output[attribute_name] = str(attribute)\n\n\n\n\n\nAdvanced serializer usage\n\n\nOverriding serialization and deserialization behavior\n\n\nIf you need to alter the serialization or deserialization behavior of a serializer class, you can do so by overriding the \n.to_representation()\n or \n.to_internal_value()\n methods.\n\n\nSome reasons this might be useful include...\n\n\n\n\nAdding new behavior for new serializer base classes.\n\n\nModifying the behavior slightly for an existing class.\n\n\nImproving serialization performance for a frequently accessed API endpoint that returns lots of data.\n\n\n\n\nThe signatures for these methods are as follows:\n\n\n.to_representation(self, obj)\n\n\nTakes the object instance that requires serialization, and should return a primitive representation. Typically this means returning a structure of built-in Python datatypes. The exact types that can be handled will depend on the render classes you have configured for your API.\n\n\nMay be overridden in order modify the representation style. For example:\n\n\ndef to_representation(self, instance):\n \"\"\"Convert `username` to lowercase.\"\"\"\n ret = super().to_representation(instance)\n ret['username'] = ret['username'].lower()\n return ret\n\n\n\n.to_internal_value(self, data)\n\n\nTakes the unvalidated incoming data as input and should return the validated data that will be made available as \nserializer.validated_data\n. The return value will also be passed to the \n.create()\n or \n.update()\n methods if \n.save()\n is called on the serializer class.\n\n\nIf any of the validation fails, then the method should raise a \nserializers.ValidationError(errors)\n. The \nerrors\n argument should be a dictionary mapping field names (or \nsettings.NON_FIELD_ERRORS_KEY\n) to a list of error messages. If you don't need to alter deserialization behavior and instead want to provide object-level validation, it's recommended that you instead override the \n.validate()\n method.\n\n\nThe \ndata\n argument passed to this method will normally be the value of \nrequest.data\n, so the datatype it provides will depend on the parser classes you have configured for your API.\n\n\nSerializer Inheritance\n\n\nSimilar to Django forms, you can extend and reuse serializers through inheritance. This allows you to declare a common set of fields or methods on a parent class that can then be used in a number of serializers. For example,\n\n\nclass MyBaseSerializer(Serializer):\n my_field = serializers.CharField()\n\n def validate_my_field(self, value):\n ...\n\nclass MySerializer(MyBaseSerializer):\n ...\n\n\n\nLike Django's \nModel\n and \nModelForm\n classes, the inner \nMeta\n class on serializers does not implicitly inherit from it's parents' inner \nMeta\n classes. If you want the \nMeta\n class to inherit from a parent class you must do so explicitly. For example:\n\n\nclass AccountSerializer(MyBaseSerializer):\n class Meta(MyBaseSerializer.Meta):\n model = Account\n\n\n\nTypically we would recommend \nnot\n using inheritance on inner Meta classes, but instead declaring all options explicitly.\n\n\nAdditionally, the following caveats apply to serializer inheritance:\n\n\n\n\nNormal Python name resolution rules apply. If you have multiple base classes that declare a \nMeta\n inner class, only the first one will be used. This means the child\u2019s \nMeta\n, if it exists, otherwise the \nMeta\n of the first parent, etc.\n\n\n\n\nIt\u2019s possible to declaratively remove a \nField\n inherited from a parent class by setting the name to be \nNone\n on the subclass.\n\n\nclass MyBaseSerializer(ModelSerializer):\n my_field = serializers.CharField()\n\nclass MySerializer(MyBaseSerializer):\n my_field = None\n\n\n\nHowever, you can only use this technique to opt out from a field defined declaratively by a parent class; it won\u2019t prevent the \nModelSerializer\n from generating a default field. To opt-out from default fields, see \nSpecifying which fields to include\n.\n\n\n\n\n\n\nDynamically modifying fields\n\n\nOnce a serializer has been initialized, the dictionary of fields that are set on the serializer may be accessed using the \n.fields\n attribute. Accessing and modifying this attribute allows you to dynamically modify the serializer.\n\n\nModifying the \nfields\n argument directly allows you to do interesting things such as changing the arguments on serializer fields at runtime, rather than at the point of declaring the serializer.\n\n\nExample\n\n\nFor example, if you wanted to be able to set which fields should be used by a serializer at the point of initializing it, you could create a serializer class like so:\n\n\nclass DynamicFieldsModelSerializer(serializers.ModelSerializer):\n \"\"\"\n A ModelSerializer that takes an additional `fields` argument that\n controls which fields should be displayed.\n \"\"\"\n\n def __init__(self, *args, **kwargs):\n # Don't pass the 'fields' arg up to the superclass\n fields = kwargs.pop('fields', None)\n\n # Instantiate the superclass normally\n super(DynamicFieldsModelSerializer, self).__init__(*args, **kwargs)\n\n if fields is not None:\n # Drop any fields that are not specified in the `fields` argument.\n allowed = set(fields)\n existing = set(self.fields)\n for field_name in existing - allowed:\n self.fields.pop(field_name)\n\n\n\nThis would then allow you to do the following:\n\n\n>>> class UserSerializer(DynamicFieldsModelSerializer):\n>>> class Meta:\n>>> model = User\n>>> fields = ('id', 'username', 'email')\n>>>\n>>> print UserSerializer(user)\n{'id': 2, 'username': 'jonwatts', 'email': 'jon@example.com'}\n>>>\n>>> print UserSerializer(user, fields=('id', 'email'))\n{'id': 2, 'email': 'jon@example.com'}\n\n\n\nCustomizing the default fields\n\n\nREST framework 2 provided an API to allow developers to override how a \nModelSerializer\n class would automatically generate the default set of fields.\n\n\nThis API included the \n.get_field()\n, \n.get_pk_field()\n and other methods.\n\n\nBecause the serializers have been fundamentally redesigned with 3.0 this API no longer exists. You can still modify the fields that get created but you'll need to refer to the source code, and be aware that if the changes you make are against private bits of API then they may be subject to change.\n\n\n\n\nThird party packages\n\n\nThe following third party packages are also available.\n\n\nDjango REST marshmallow\n\n\nThe \ndjango-rest-marshmallow\n package provides an alternative implementation for serializers, using the python \nmarshmallow\n library. It exposes the same API as the REST framework serializers, and can be used as a drop-in replacement in some use-cases.\n\n\nSerpy\n\n\nThe \nserpy\n package is an alternative implementation for serializers that is built for speed. \nSerpy\n serializes complex datatypes to simple native types. The native types can be easily converted to JSON or any other format needed.\n\n\nMongoengineModelSerializer\n\n\nThe \ndjango-rest-framework-mongoengine\n package provides a \nMongoEngineModelSerializer\n serializer class that supports using MongoDB as the storage layer for Django REST framework.\n\n\nGeoFeatureModelSerializer\n\n\nThe \ndjango-rest-framework-gis\n package provides a \nGeoFeatureModelSerializer\n serializer class that supports GeoJSON both for read and write operations.\n\n\nHStoreSerializer\n\n\nThe \ndjango-rest-framework-hstore\n package provides an \nHStoreSerializer\n to support \ndjango-hstore\n \nDictionaryField\n model field and its \nschema-mode\n feature.\n\n\nDynamic REST\n\n\nThe \ndynamic-rest\n package extends the ModelSerializer and ModelViewSet interfaces, adding API query parameters for filtering, sorting, and including / excluding all fields and relationships defined by your serializers.\n\n\nDynamic Fields Mixin\n\n\nThe \ndrf-dynamic-fields\n package provides a mixin to dynamically limit the fields per serializer to a subset specified by an URL parameter.\n\n\nDRF FlexFields\n\n\nThe \ndrf-flex-fields\n package extends the ModelSerializer and ModelViewSet to provide commonly used functionality for dynamically setting fields and expanding primitive fields to nested models, both from URL parameters and your serializer class definitions.\n\n\nSerializer Extensions\n\n\nThe \ndjango-rest-framework-serializer-extensions\n\npackage provides a collection of tools to DRY up your serializers, by allowing\nfields to be defined on a per-view/request basis. Fields can be whitelisted,\nblacklisted and child serializers can be optionally expanded.\n\n\nHTML JSON Forms\n\n\nThe \nhtml-json-forms\n package provides an algorithm and serializer for processing \n\n submissions per the (inactive) \nHTML JSON Form specification\n. The serializer facilitates processing of arbitrarily nested JSON structures within HTML. For example, \n\n will be interpreted as \n{\"items\": [{\"id\": \"5\"}]}\n.\n\n\nDRF-Base64\n\n\nDRF-Base64\n provides a set of field and model serializers that handles the upload of base64-encoded files.\n\n\nQueryFields\n\n\ndjangorestframework-queryfields\n allows API clients to specify which fields will be sent in the response via inclusion/exclusion query parameters.\n\n\nDRF Writable Nested\n\n\nThe \ndrf-writable-nested\n package provides writable nested model serializer which allows to create/update models with nested related data.", "title": "Serializers" }, { @@ -1417,7 +1417,7 @@ }, { "location": "/api-guide/serializers/#object-level-validation", - "text": "To do any other validation that requires access to multiple fields, add a method called .validate() to your Serializer subclass. This method takes a single argument, which is a dictionary of field values. It should raise a serializers.ValidationError if necessary, or just return the validated values. For example: from rest_framework import serializers\n\nclass EventSerializer(serializers.Serializer):\n description = serializers.CharField(max_length=100)\n start = serializers.DateTimeField()\n finish = serializers.DateTimeField()\n\n def validate(self, data):\n \"\"\"\n Check that the start is before the stop.\n \"\"\"\n if data['start'] > data['finish']:\n raise serializers.ValidationError(\"finish must occur after start\")\n return data", + "text": "To do any other validation that requires access to multiple fields, add a method called .validate() to your Serializer subclass. This method takes a single argument, which is a dictionary of field values. It should raise a serializers.ValidationError if necessary, or just return the validated values. For example: from rest_framework import serializers\n\nclass EventSerializer(serializers.Serializer):\n description = serializers.CharField(max_length=100)\n start = serializers.DateTimeField()\n finish = serializers.DateTimeField()\n\n def validate(self, data):\n \"\"\"\n Check that start is before finish.\n \"\"\"\n if data['start'] > data['finish']:\n raise serializers.ValidationError(\"finish must occur after start\")\n return data", "title": "Object-level validation" }, { diff --git a/sitemap.xml b/sitemap.xml index 9f32a1153..599e51bfb 100644 --- a/sitemap.xml +++ b/sitemap.xml @@ -4,7 +4,7 @@ https://www.django-rest-framework.org// - 2018-11-15 + 2018-11-16 daily @@ -13,49 +13,49 @@ https://www.django-rest-framework.org//tutorial/quickstart/ - 2018-11-15 + 2018-11-16 daily https://www.django-rest-framework.org//tutorial/1-serialization/ - 2018-11-15 + 2018-11-16 daily https://www.django-rest-framework.org//tutorial/2-requests-and-responses/ - 2018-11-15 + 2018-11-16 daily https://www.django-rest-framework.org//tutorial/3-class-based-views/ - 2018-11-15 + 2018-11-16 daily https://www.django-rest-framework.org//tutorial/4-authentication-and-permissions/ - 2018-11-15 + 2018-11-16 daily https://www.django-rest-framework.org//tutorial/5-relationships-and-hyperlinked-apis/ - 2018-11-15 + 2018-11-16 daily https://www.django-rest-framework.org//tutorial/6-viewsets-and-routers/ - 2018-11-15 + 2018-11-16 daily https://www.django-rest-framework.org//tutorial/7-schemas-and-client-libraries/ - 2018-11-15 + 2018-11-16 daily @@ -65,169 +65,169 @@ https://www.django-rest-framework.org//api-guide/requests/ - 2018-11-15 + 2018-11-16 daily https://www.django-rest-framework.org//api-guide/responses/ - 2018-11-15 + 2018-11-16 daily https://www.django-rest-framework.org//api-guide/views/ - 2018-11-15 + 2018-11-16 daily https://www.django-rest-framework.org//api-guide/generic-views/ - 2018-11-15 + 2018-11-16 daily https://www.django-rest-framework.org//api-guide/viewsets/ - 2018-11-15 + 2018-11-16 daily https://www.django-rest-framework.org//api-guide/routers/ - 2018-11-15 + 2018-11-16 daily https://www.django-rest-framework.org//api-guide/parsers/ - 2018-11-15 + 2018-11-16 daily https://www.django-rest-framework.org//api-guide/renderers/ - 2018-11-15 + 2018-11-16 daily https://www.django-rest-framework.org//api-guide/serializers/ - 2018-11-15 + 2018-11-16 daily https://www.django-rest-framework.org//api-guide/fields/ - 2018-11-15 + 2018-11-16 daily https://www.django-rest-framework.org//api-guide/relations/ - 2018-11-15 + 2018-11-16 daily https://www.django-rest-framework.org//api-guide/validators/ - 2018-11-15 + 2018-11-16 daily https://www.django-rest-framework.org//api-guide/authentication/ - 2018-11-15 + 2018-11-16 daily https://www.django-rest-framework.org//api-guide/permissions/ - 2018-11-15 + 2018-11-16 daily https://www.django-rest-framework.org//api-guide/caching/ - 2018-11-15 + 2018-11-16 daily https://www.django-rest-framework.org//api-guide/throttling/ - 2018-11-15 + 2018-11-16 daily https://www.django-rest-framework.org//api-guide/filtering/ - 2018-11-15 + 2018-11-16 daily https://www.django-rest-framework.org//api-guide/pagination/ - 2018-11-15 + 2018-11-16 daily https://www.django-rest-framework.org//api-guide/versioning/ - 2018-11-15 + 2018-11-16 daily https://www.django-rest-framework.org//api-guide/content-negotiation/ - 2018-11-15 + 2018-11-16 daily https://www.django-rest-framework.org//api-guide/metadata/ - 2018-11-15 + 2018-11-16 daily https://www.django-rest-framework.org//api-guide/schemas/ - 2018-11-15 + 2018-11-16 daily https://www.django-rest-framework.org//api-guide/format-suffixes/ - 2018-11-15 + 2018-11-16 daily https://www.django-rest-framework.org//api-guide/reverse/ - 2018-11-15 + 2018-11-16 daily https://www.django-rest-framework.org//api-guide/exceptions/ - 2018-11-15 + 2018-11-16 daily https://www.django-rest-framework.org//api-guide/status-codes/ - 2018-11-15 + 2018-11-16 daily https://www.django-rest-framework.org//api-guide/testing/ - 2018-11-15 + 2018-11-16 daily https://www.django-rest-framework.org//api-guide/settings/ - 2018-11-15 + 2018-11-16 daily @@ -237,49 +237,49 @@ https://www.django-rest-framework.org//topics/documenting-your-api/ - 2018-11-15 + 2018-11-16 daily https://www.django-rest-framework.org//topics/api-clients/ - 2018-11-15 + 2018-11-16 daily https://www.django-rest-framework.org//topics/internationalization/ - 2018-11-15 + 2018-11-16 daily https://www.django-rest-framework.org//topics/ajax-csrf-cors/ - 2018-11-15 + 2018-11-16 daily https://www.django-rest-framework.org//topics/html-and-forms/ - 2018-11-15 + 2018-11-16 daily https://www.django-rest-framework.org//topics/browser-enhancements/ - 2018-11-15 + 2018-11-16 daily https://www.django-rest-framework.org//topics/browsable-api/ - 2018-11-15 + 2018-11-16 daily https://www.django-rest-framework.org//topics/rest-hypermedia-hateoas/ - 2018-11-15 + 2018-11-16 daily @@ -289,115 +289,115 @@ https://www.django-rest-framework.org//community/tutorials-and-resources/ - 2018-11-15 + 2018-11-16 daily https://www.django-rest-framework.org//community/third-party-packages/ - 2018-11-15 + 2018-11-16 daily https://www.django-rest-framework.org//community/contributing/ - 2018-11-15 + 2018-11-16 daily https://www.django-rest-framework.org//community/project-management/ - 2018-11-15 + 2018-11-16 daily https://www.django-rest-framework.org//community/release-notes/ - 2018-11-15 + 2018-11-16 daily https://www.django-rest-framework.org//community/3.9-announcement/ - 2018-11-15 + 2018-11-16 daily https://www.django-rest-framework.org//community/3.8-announcement/ - 2018-11-15 + 2018-11-16 daily https://www.django-rest-framework.org//community/3.7-announcement/ - 2018-11-15 + 2018-11-16 daily https://www.django-rest-framework.org//community/3.6-announcement/ - 2018-11-15 + 2018-11-16 daily https://www.django-rest-framework.org//community/3.5-announcement/ - 2018-11-15 + 2018-11-16 daily https://www.django-rest-framework.org//community/3.4-announcement/ - 2018-11-15 + 2018-11-16 daily https://www.django-rest-framework.org//community/3.3-announcement/ - 2018-11-15 + 2018-11-16 daily https://www.django-rest-framework.org//community/3.2-announcement/ - 2018-11-15 + 2018-11-16 daily https://www.django-rest-framework.org//community/3.1-announcement/ - 2018-11-15 + 2018-11-16 daily https://www.django-rest-framework.org//community/3.0-announcement/ - 2018-11-15 + 2018-11-16 daily https://www.django-rest-framework.org//community/kickstarter-announcement/ - 2018-11-15 + 2018-11-16 daily https://www.django-rest-framework.org//community/mozilla-grant/ - 2018-11-15 + 2018-11-16 daily https://www.django-rest-framework.org//community/funding/ - 2018-11-15 + 2018-11-16 daily https://www.django-rest-framework.org//community/jobs/ - 2018-11-15 + 2018-11-16 daily