From 2352e2d28691e36b9cdaa03ce7bc83866b862fa7 Mon Sep 17 00:00:00 2001 From: Tom Christie Date: Sat, 25 Feb 2017 19:59:44 +0000 Subject: [PATCH] Deployed e922d916 with MkDocs version: 0.15.3 --- 404.html | 10 +- api-guide/authentication/index.html | 10 +- api-guide/content-negotiation/index.html | 10 +- api-guide/exceptions/index.html | 10 +- api-guide/fields/index.html | 11 +- api-guide/filtering/index.html | 10 +- api-guide/format-suffixes/index.html | 10 +- api-guide/generic-views/index.html | 10 +- api-guide/metadata/index.html | 10 +- api-guide/pagination/index.html | 10 +- api-guide/parsers/index.html | 10 +- api-guide/permissions/index.html | 10 +- api-guide/relations/index.html | 10 +- api-guide/renderers/index.html | 10 +- api-guide/requests/index.html | 10 +- api-guide/responses/index.html | 10 +- api-guide/reverse/index.html | 10 +- api-guide/routers/index.html | 10 +- api-guide/schemas/index.html | 10 +- api-guide/serializers/index.html | 17 +- api-guide/settings/index.html | 10 +- api-guide/status-codes/index.html | 10 +- api-guide/testing/index.html | 10 +- api-guide/throttling/index.html | 10 +- api-guide/validators/index.html | 10 +- api-guide/versioning/index.html | 10 +- api-guide/views/index.html | 10 +- api-guide/viewsets/index.html | 10 +- img/premium/micropyramid-readme.png | Bin 0 -> 23782 bytes index.html | 17 +- mkdocs/search_index.json | 140 ++-- sitemap.xml | 128 ++-- topics/3.0-announcement/index.html | 10 +- topics/3.1-announcement/index.html | 10 +- topics/3.2-announcement/index.html | 10 +- topics/3.3-announcement/index.html | 10 +- topics/3.4-announcement/index.html | 10 +- topics/3.5-announcement/index.html | 10 +- topics/ajax-csrf-cors/index.html | 10 +- topics/api-clients/index.html | 10 +- topics/browsable-api/index.html | 10 +- topics/browser-enhancements/index.html | 10 +- topics/contributing/index.html | 12 +- topics/documenting-your-api/index.html | 10 +- topics/funding/index.html | 10 +- topics/html-and-forms/index.html | 10 +- topics/internationalization/index.html | 10 +- topics/jobs/index.html | 466 +++++++++++++ topics/kickstarter-announcement/index.html | 10 +- topics/mozilla-grant/index.html | 10 +- topics/project-management/index.html | 10 +- topics/release-notes/index.html | 12 +- topics/rest-hypermedia-hateoas/index.html | 12 +- topics/third-party-packages/index.html | 655 ++++++++++++++++++ topics/tutorials-and-resources/index.html | 521 ++++++++++++++ tutorial/1-serialization/index.html | 10 +- tutorial/2-requests-and-responses/index.html | 10 +- tutorial/3-class-based-views/index.html | 10 +- .../index.html | 10 +- .../index.html | 10 +- tutorial/6-viewsets-and-routers/index.html | 10 +- .../7-schemas-and-client-libraries/index.html | 10 +- tutorial/quickstart/index.html | 10 +- 63 files changed, 2329 insertions(+), 172 deletions(-) create mode 100644 img/premium/micropyramid-readme.png create mode 100644 topics/jobs/index.html create mode 100644 topics/third-party-packages/index.html create mode 100644 topics/tutorials-and-resources/index.html diff --git a/404.html b/404.html index 6330872e6..565966c1f 100644 --- a/404.html +++ b/404.html @@ -271,7 +271,11 @@
  • - Third Party Resources + Third Party Packages +
    • + +
  • + Tutorials and Resources
  • @@ -322,6 +326,10 @@ Release Notes
    • +
  • + Jobs +
    • + diff --git a/api-guide/authentication/index.html b/api-guide/authentication/index.html index 9b38ca47d..3b4cb41f9 100644 --- a/api-guide/authentication/index.html +++ b/api-guide/authentication/index.html @@ -271,7 +271,11 @@
  • - Third Party Resources + Third Party Packages +
    • + +
  • + Tutorials and Resources
  • @@ -322,6 +326,10 @@ Release Notes
    • +
  • + Jobs +
    • + diff --git a/api-guide/content-negotiation/index.html b/api-guide/content-negotiation/index.html index bc296cde7..ef717d99b 100644 --- a/api-guide/content-negotiation/index.html +++ b/api-guide/content-negotiation/index.html @@ -271,7 +271,11 @@
  • - Third Party Resources + Third Party Packages +
    • + +
  • + Tutorials and Resources
  • @@ -322,6 +326,10 @@ Release Notes
    • +
  • + Jobs +
    • + diff --git a/api-guide/exceptions/index.html b/api-guide/exceptions/index.html index bccdbc6b2..ac1c968d9 100644 --- a/api-guide/exceptions/index.html +++ b/api-guide/exceptions/index.html @@ -271,7 +271,11 @@
  • - Third Party Resources + Third Party Packages +
    • + +
  • + Tutorials and Resources
  • @@ -322,6 +326,10 @@ Release Notes
    • +
  • + Jobs +
    • + diff --git a/api-guide/fields/index.html b/api-guide/fields/index.html index 7bd3aff96..645417d36 100644 --- a/api-guide/fields/index.html +++ b/api-guide/fields/index.html @@ -271,7 +271,11 @@
  • - Third Party Resources + Third Party Packages +
    • + +
  • + Tutorials and Resources
  • @@ -322,6 +326,10 @@ Release Notes
    • +
  • + Jobs +
    • + @@ -789,7 +797,6 @@ color_channel = serializers.ChoiceField(

    DateTimeField format strings.

    Format strings may either be Python strftime formats which explicitly specify the format, or the special string 'iso-8601', which indicates that ISO 8601 style datetimes should be used. (eg '2013-01-29T12:34:56.000000Z')

    When a value of None is used for the format datetime objects will be returned by to_representation and the final output representation will determined by the renderer class.

    -

    In the case of JSON this means the default datetime representation uses the ECMA 262 date time string specification. This is a subset of ISO 8601 which uses millisecond precision, and includes the 'Z' suffix for the UTC timezone, for example: 2013-01-29T12:34:56.123Z.

    auto_now_add model fields.auto_now and

    When using ModelSerializer or HyperlinkedModelSerializer, note that any model fields with auto_now=True or auto_now_add=True will use serializer fields that are read_only=True by default.

    If you want to override this behavior, you'll need to declare the DateTimeField explicitly on the serializer. For example:

    diff --git a/api-guide/filtering/index.html b/api-guide/filtering/index.html index 887118583..6f3c07e87 100644 --- a/api-guide/filtering/index.html +++ b/api-guide/filtering/index.html @@ -271,7 +271,11 @@
  • - Third Party Resources + Third Party Packages +
    • + +
  • + Tutorials and Resources
  • @@ -322,6 +326,10 @@ Release Notes
    • +
  • + Jobs +
    • + diff --git a/api-guide/format-suffixes/index.html b/api-guide/format-suffixes/index.html index fde9b2218..d2b8479f5 100644 --- a/api-guide/format-suffixes/index.html +++ b/api-guide/format-suffixes/index.html @@ -271,7 +271,11 @@
  • - Third Party Resources + Third Party Packages +
    • + +
  • + Tutorials and Resources
  • @@ -322,6 +326,10 @@ Release Notes
    • +
  • + Jobs +
    • + diff --git a/api-guide/generic-views/index.html b/api-guide/generic-views/index.html index 43fcf90bf..ed5a0ec15 100644 --- a/api-guide/generic-views/index.html +++ b/api-guide/generic-views/index.html @@ -271,7 +271,11 @@
  • - Third Party Resources + Third Party Packages +
    • + +
  • + Tutorials and Resources
  • @@ -322,6 +326,10 @@ Release Notes
    • +
  • + Jobs +
    • + diff --git a/api-guide/metadata/index.html b/api-guide/metadata/index.html index a37a1bd50..628f3740b 100644 --- a/api-guide/metadata/index.html +++ b/api-guide/metadata/index.html @@ -271,7 +271,11 @@
  • - Third Party Resources + Third Party Packages +
    • + +
  • + Tutorials and Resources
  • @@ -322,6 +326,10 @@ Release Notes
    • +
  • + Jobs +
    • + diff --git a/api-guide/pagination/index.html b/api-guide/pagination/index.html index 8179e2e7d..2f8e22592 100644 --- a/api-guide/pagination/index.html +++ b/api-guide/pagination/index.html @@ -271,7 +271,11 @@
  • - Third Party Resources + Third Party Packages +
    • + +
  • + Tutorials and Resources
  • @@ -322,6 +326,10 @@ Release Notes
    • +
  • + Jobs +
    • + diff --git a/api-guide/parsers/index.html b/api-guide/parsers/index.html index a1b0f9e73..544263321 100644 --- a/api-guide/parsers/index.html +++ b/api-guide/parsers/index.html @@ -271,7 +271,11 @@
  • - Third Party Resources + Third Party Packages +
    • + +
  • + Tutorials and Resources
  • @@ -322,6 +326,10 @@ Release Notes
    • +
  • + Jobs +
    • + diff --git a/api-guide/permissions/index.html b/api-guide/permissions/index.html index 1b3ad664a..8ff3e3cda 100644 --- a/api-guide/permissions/index.html +++ b/api-guide/permissions/index.html @@ -271,7 +271,11 @@
  • - Third Party Resources + Third Party Packages +
    • + +
  • + Tutorials and Resources
  • @@ -322,6 +326,10 @@ Release Notes
    • +
  • + Jobs +
    • + diff --git a/api-guide/relations/index.html b/api-guide/relations/index.html index 4b694e3f1..20d0022b6 100644 --- a/api-guide/relations/index.html +++ b/api-guide/relations/index.html @@ -271,7 +271,11 @@
  • - Third Party Resources + Third Party Packages +
    • + +
  • + Tutorials and Resources
  • @@ -322,6 +326,10 @@ Release Notes
    • +
  • + Jobs +
    • + diff --git a/api-guide/renderers/index.html b/api-guide/renderers/index.html index e3734815f..5330d80b4 100644 --- a/api-guide/renderers/index.html +++ b/api-guide/renderers/index.html @@ -271,7 +271,11 @@
  • - Third Party Resources + Third Party Packages +
    • + +
  • + Tutorials and Resources
  • @@ -322,6 +326,10 @@ Release Notes
    • +
  • + Jobs +
    • + diff --git a/api-guide/requests/index.html b/api-guide/requests/index.html index 1edaaad7b..41e4f6d80 100644 --- a/api-guide/requests/index.html +++ b/api-guide/requests/index.html @@ -271,7 +271,11 @@
  • - Third Party Resources + Third Party Packages +
    • + +
  • + Tutorials and Resources
  • @@ -322,6 +326,10 @@ Release Notes
    • +
  • + Jobs +
    • + diff --git a/api-guide/responses/index.html b/api-guide/responses/index.html index 8a6a7732f..f533553b0 100644 --- a/api-guide/responses/index.html +++ b/api-guide/responses/index.html @@ -271,7 +271,11 @@
  • - Third Party Resources + Third Party Packages +
    • + +
  • + Tutorials and Resources
  • @@ -322,6 +326,10 @@ Release Notes
    • +
  • + Jobs +
    • + diff --git a/api-guide/reverse/index.html b/api-guide/reverse/index.html index 4402c1f99..2b1f7484e 100644 --- a/api-guide/reverse/index.html +++ b/api-guide/reverse/index.html @@ -271,7 +271,11 @@
  • - Third Party Resources + Third Party Packages +
    • + +
  • + Tutorials and Resources
  • @@ -322,6 +326,10 @@ Release Notes
    • +
  • + Jobs +
    • + diff --git a/api-guide/routers/index.html b/api-guide/routers/index.html index 4d4e366c5..8d976ff77 100644 --- a/api-guide/routers/index.html +++ b/api-guide/routers/index.html @@ -271,7 +271,11 @@
  • - Third Party Resources + Third Party Packages +
    • + +
  • + Tutorials and Resources
  • @@ -322,6 +326,10 @@ Release Notes
    • +
  • + Jobs +
    • + diff --git a/api-guide/schemas/index.html b/api-guide/schemas/index.html index 53e1a0955..8351748c3 100644 --- a/api-guide/schemas/index.html +++ b/api-guide/schemas/index.html @@ -271,7 +271,11 @@
  • - Third Party Resources + Third Party Packages +
    • + +
  • + Tutorials and Resources
  • @@ -322,6 +326,10 @@ Release Notes
    • +
  • + Jobs +
    • + diff --git a/api-guide/serializers/index.html b/api-guide/serializers/index.html index 0deeb77b7..8c790b309 100644 --- a/api-guide/serializers/index.html +++ b/api-guide/serializers/index.html @@ -271,7 +271,11 @@
  • - Third Party Resources + Third Party Packages +
    • + +
  • + Tutorials and Resources
  • @@ -322,6 +326,10 @@ Release Notes
    • +
  • + Jobs +
    • + @@ -578,6 +586,10 @@ QueryFields +
  • + DRF Writable Nested +
    • +
    @@ -1450,7 +1462,6 @@ class MySerializer(MyBaseSerializer):

    REST framework 2 provided an API to allow developers to override how a ModelSerializer class would automatically generate the default set of fields.

    This API included the .get_field(), .get_pk_field() and other methods.

    Because 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.

    -

    A new interface for controlling this behavior is currently planned for REST framework 3.1.

    Third party packages

    The following third party packages are also available.

    @@ -1481,6 +1492,8 @@ blacklisted and child serializers can be optionally expanded.

    DRF-Base64 provides a set of field and model serializers that handles the upload of base64-encoded files.

    QueryFields

    djangorestframework-queryfields allows API clients to specify which fields will be sent in the response via inclusion/exclusion query parameters.

    +

    DRF Writable Nested

    +

    The drf-writable-nested package provides writable nested model serializer which allows to create/update models with nested related data.

    diff --git a/api-guide/settings/index.html b/api-guide/settings/index.html index 37b4f4e71..ae6828fe9 100644 --- a/api-guide/settings/index.html +++ b/api-guide/settings/index.html @@ -271,7 +271,11 @@
  • - Third Party Resources + Third Party Packages +
    • + +
  • + Tutorials and Resources
  • @@ -322,6 +326,10 @@ Release Notes
    • +
  • + Jobs +
    • + diff --git a/api-guide/status-codes/index.html b/api-guide/status-codes/index.html index 294b4c915..b555845ca 100644 --- a/api-guide/status-codes/index.html +++ b/api-guide/status-codes/index.html @@ -271,7 +271,11 @@
  • - Third Party Resources + Third Party Packages +
    • + +
  • + Tutorials and Resources
  • @@ -322,6 +326,10 @@ Release Notes
    • +
  • + Jobs +
    • + diff --git a/api-guide/testing/index.html b/api-guide/testing/index.html index c2a8bc044..d586e71d8 100644 --- a/api-guide/testing/index.html +++ b/api-guide/testing/index.html @@ -271,7 +271,11 @@
  • - Third Party Resources + Third Party Packages +
    • + +
  • + Tutorials and Resources
  • @@ -322,6 +326,10 @@ Release Notes
    • +
  • + Jobs +
    • + diff --git a/api-guide/throttling/index.html b/api-guide/throttling/index.html index 0057e4038..d38baf817 100644 --- a/api-guide/throttling/index.html +++ b/api-guide/throttling/index.html @@ -271,7 +271,11 @@
  • - Third Party Resources + Third Party Packages +
    • + +
  • + Tutorials and Resources
  • @@ -322,6 +326,10 @@ Release Notes
    • +
  • + Jobs +
    • + diff --git a/api-guide/validators/index.html b/api-guide/validators/index.html index 307dde9ed..b29d1e01b 100644 --- a/api-guide/validators/index.html +++ b/api-guide/validators/index.html @@ -271,7 +271,11 @@
  • - Third Party Resources + Third Party Packages +
    • + +
  • + Tutorials and Resources
  • @@ -322,6 +326,10 @@ Release Notes
    • +
  • + Jobs +
    • + diff --git a/api-guide/versioning/index.html b/api-guide/versioning/index.html index b635fbced..0de883432 100644 --- a/api-guide/versioning/index.html +++ b/api-guide/versioning/index.html @@ -271,7 +271,11 @@
  • - Third Party Resources + Third Party Packages +
    • + +
  • + Tutorials and Resources
  • @@ -322,6 +326,10 @@ Release Notes
    • +
  • + Jobs +
    • + diff --git a/api-guide/views/index.html b/api-guide/views/index.html index 4e57a6549..cd6c36dd8 100644 --- a/api-guide/views/index.html +++ b/api-guide/views/index.html @@ -271,7 +271,11 @@
  • - Third Party Resources + Third Party Packages +
    • + +
  • + Tutorials and Resources
  • @@ -322,6 +326,10 @@ Release Notes
    • +
  • + Jobs +
    • + diff --git a/api-guide/viewsets/index.html b/api-guide/viewsets/index.html index 67779867f..60309d6a9 100644 --- a/api-guide/viewsets/index.html +++ b/api-guide/viewsets/index.html @@ -271,7 +271,11 @@
  • - Third Party Resources + Third Party Packages +
    • + +
  • + Tutorials and Resources
  • @@ -322,6 +326,10 @@ Release Notes
    • +
  • + Jobs +
    • + diff --git a/img/premium/micropyramid-readme.png b/img/premium/micropyramid-readme.png new file mode 100644 index 0000000000000000000000000000000000000000..9fa9500e14b2a9c215a112ef7ddb1f4f377538db GIT binary patch literal 23782 zcmeFZbyQqUvo|_}OK=Sk7+`QG!QBVR@cf>S5>jA`Jitdhov#?aW+_Kpu9s_AdM$LR5cC@V}J*BC}C}{uXhy5u*B_r~;C3 za5e*RvA$zvrxHd3fk1-Jrsn)=lG6W%ztn`NEL~k4`PtZ@P$(<(EvtjG1sew+A0Hb# zCmSax%Zmhyi>JM-kq3*t3-!Mm`LA{)&0I{JtsGsg9PB}VwQFST;N~hsMfI1W|Ni`| zpRQKs|D(y?<=p7X1jxj5Lm{pA8pdn;FAPQkwo z`cLxzc;sIw2?skzXEPU<7nm^Dzajsm{ipng|4}2%^ItmtN&HWMva{8TrAB}COPJ%| z3jRs^Px+7kn}UB5{{i^R_53PU9%i;5B&}W?`nMIFd@tSlUpfDYlyI=kW=5_K&KeF5 zw!(j#VfR-R^p=(TU&w#*{|yyn`)eHiV_f}f(Ed$*8MVS_FUbG80tlm-93Q5W$BS~VOHg-hVt0YlwGV2FSlpp z$CBTrYz^`k-9_&! znx1>PRmJUtldQVz^DUtP#2oKDz=(E2KXAPp|4%oWYH03HjEUj~D>8OWV&vLCFrXT@ zZkf^SMW;e_9p(fg#UuuqediJw zc#%Ts0m2u6Y#XGbUf{O8hOk78nFF%Fq)?Dw#eS}yCgJ-3mHdC&T{$2~*>B7DWIM#o z`(7c(EyF#0mF3-81PNxw&)qo!p1DJBggqxNudds^B@F-yX(vL1P#eT?+f8 z>~GhC?Dt!f>@UOnei`c{L1Jz=F?Nqy<^&E#-7uTw^&~32cPh(R)ArwM;kP0^o_3lp zPazcX_%Rgtk7H}JZ50$?%?a#`}nXlrU!M%CM71r z1u5Ds2Q@z)p+@#%YN=|k{VvyC%bM#L>Towq(P?P^O+ct{NF&l9L$qeCSi_AB#(8|O zPPuRUp?Bmukdt22C*XRWrK738^YplNdvrRFtEDB}K%|+y=so^;-avkBuHJNCYS(>fX#_6>AtP!-S~AG6fj+_&iG0v2 zw$K+&zTEi8&i-lUQO@ONp$c*xRQ_ zEahGeK3<-d?3JD3s_Inm)qndZ();?zOCJESU|VvOfGaLhdN}|)Xq4~$N~G=sBHmQ0 zmXb8)tMyVVyVMtF3d~M!6QgXV**-}G{>Jwd?3XP_CMY@M6|zVKz0-}* z_bwz?B-o4fa&Pq+_nBTkw!gw?^E9D1MUm9<4qi0KK6Xth{2UAh=Vg+TE+#j)*<<}4H z;jg7iTvxhgcgKFLI}RM8xt-Ic2NZl`RmseP^OUC%d$Rxxj zA+V;}V~vi`T4i9h`u<$K;wVAKC+5>{LC;$gW)bUyvm;-a3-emDI8dr^>m>NqHF2i| z-YNGz)ZQ^^ljc`XC}}u_1e}RR{Y>`KVPl2C>(cbu1uoI>%)(t#$<4b5_iS$oq*e10 zKB?XJ&T@EPYU2tp8!uX$s;&zj(z0V<=m=Mzjz6`foDln6bUZsn`o(74w6P|gS8I$Z z+h4Z2Bf^67kbsj-Su6X=QyNT!7I_mvBz^gIMC_%kY;ODSS>0^*2)!5P^WUg$b&!J0 zM$0mydy}5y+RdA9*q}ei!2u58Zv^b_SKp_8rjD@`d)`qi5-9sX0Y`r>3&7diG6L?6 zRbqb~7h$NPD5c|&6Nyih{HcZl=U3fUQDv~#>AuR*1U)sgS z|8oAb&maqj_(qGh!l`Y;t+!eza}dCAGA*w8J^iZbEIu=CI3C?d=B1hwSwGF(rf{M0 zvv4VFRO*WuqqmNzhf)@2yEWp+&^NO^iZqr*m4o}$O_gAaiFVmnB*<>1Yw}9|7a(yl|MQ`38;_}091_J_9R6`yo;w}5 zf;XiC^_tTFh-Fm5;H(TwZ){XQYHY8Rs>)6b!J#4zOo)rdn%@XHOg%ie!gyM0zRM?o ziH*T&O0ISPM?x=Gg46u#KQpn6TI515Lyubt>oskw9Ht3<&le`?i^~-@kA`a-E4+2+ zX9+;HpSEU0`f(d)c!=z4v;&suQ8LzfMiW@VjaUBOoy|Hy-8%+VVKeTc*xMpQBgY-q zwQu^6Wl-0-U2Ibd0u!6`)h7M>3hl*^cHiNhnwPIQ1&mcOLyNg@qgSQ-zWPxWD`#}= zX&=>>Ih!2eQl5*#nd&RkTSTcf{K|Y43#Ti#xGoZ#-X+6h26d3tY^F5i812;@ zo>1fNr336Ir77eVi<`+um&80@E3_?W=#jmObqo<1{*obXwgfLZW54XA$O1J6g5yIN zT52`_U@VwXmt`8f-s9Y?SaO7FFMnls;%-gJ2R2#AnGX5d{#JB2Q5}yA83hMVGDrqjS)!7K@U1e$ zTGP*4Ge}1}?cPjstu>#sE;0R4K`hqEYpUP)&7QfxV9(Y|#;RT~$i#uOj<+LuMPo=tMfMS`}jj=0V15c1rRtr=tEA^8GBc^@{>#p^mcuI(h zTXaRjENxg{yFMvk)#yhOyQyFK8U1Y6$)_N2fdByOero1@Vw+EdoP_%|WZpa)r^D~2 z;C^~QW~qbN*3{$o)^J_FIZ}*+&h~UeadzrS+I^-VUUTesGWOoA*wQOs`4~a6akd~je z^wu9_@CUSmI=1-%gDj_QR-XHgHRr>$B@d_bfnC>+d35TJ5?Jh=wK~1wbfol%OkWH{qV9t+Ngit)ar_zG_ zR1|5Pl*A!-{Ng%nyf3Ed z9#g{nUcVdMT(=KC=G#;%rm9Kq5tz29XEiw6B?Tbyt@1IZpIeEr>m?+{`6x)K-itGASD!0{wI%n z${XiXk&3?dW>@`D25jQmp~h!%T->(Yab<+1b)cT(){p!I^pO$_Rk>>KCV-b zOAeR}(KeOY(8^Djl-0&l5%-N{JBy>b>FKrG+fQFIYt_*Os-c?v0ScEx$<8C@8l4wq za43EbnkDz6^Q9BQE=lHTUN3hAnKsuSudkas7B-WsGAF`Fm2PQH=sZX# z=$16N=2zP|)zR9%SfO^HN+!v-L?ORaAc+=io7X8J2bmq>c~8_LqN}&bJ=VqcrjH|~ zWJ(f+HjJ9gly$!sP)rHr<=_EoZVkYQQOjt$qzIvqszS-&y3`=#}TJwH;XkR zM=_`Q=NU_=qIKEYKT`~LC}-xUm(CZ5IIxR5_c|(ZH2T%l_B`gEO`CIGUSTyyXz47* zB@itgUX5nFy;Gfzs~z0(I}Nkz#0BdZkC}3!GJG%l(Q23c=h}qDv;du|R-)}TX<^TQ z=Q3&2zGcmQEw(?D&v*dKnhPgZh{upq#8899%|${n&imu7HEBWZh$+AORxMkPds)RV zRT41KSXz}EnA*tcW6ALG?=~Tw-_|w<9>%F(&$!tCQWZe1e8w!$q_6Jp67^ zhY$DH{bpXk;gD#-#p<4nr)n}&%+%3ono44r^yW|bI+93%1bOX<#Gm2Z~BC~MS z3&dP^`+?UaH+KxqvQK$L35OS$9o`TEs$z56mHW z&ODZ%(|BA^cG(h&Fs0ii#w$yrxRIlnu1i~HKF42S&n+UpMZav{k}-8-mq0``PgbF9 z_4j!;9@FA-gcl$4`r2iei{a%2qw;Ba#A0NUhMrp@PZh({8DDYv<1E+W9LC4D99_0@ zHhBhnPk%WpwBcDQ8W{7wen3HY_7X!spdfa>{9&{7a(_IACgINc{Z(vy3&$C`AqW(g zY4NQ8E#P=@C#sNfomel*HwdRrp>!mHk?Ab5yBJIxaV}e8Dbg~v*<^041Z)f?%?$Xu ziWkXKYPmRL_FNiKL-oy)j=>?cOgubD&x6XuSVxWx%da=q=Ugd7;Fre;mkkfjflv!> zE*xbDX6eTZHB<*LP%D6W|O=Mv;7=N!q8~wYX9kba?lZ~ zznZS3#x0c1)nh?R7sT^>Hc)DQb~THwOumw2sBW`XGl-U)L~<;pBoYBu_AshBo zA#pTVB3+_+`ZJ+>xNsinUgUAe0X;D}#C$2yb_HM+`J-oze`(^FhB_}*qKe7AMNd<8 zRbO3ODnOsIAG;*#DdN?$tZ(Dqc(~q;3LbD^R84WM?Ve^OjBnG3Z zya#mE?Y5-)dv6R)PaycN!+E_?!1pK|daka;!juHrHEBpQ4GDIIj@a3L@KMT00BFL)nD$fPC#`K6i&XqU+8 z#-#dTJnIVDtQEY7>sUlldkk7D6;=}}N{^3sL@L)H@UK=i9_2!f6u#eUZ=3w|!|nQN zsO-z(bgKxic*a z$FI-6jZ53>NpgB7CQ4Jk`YUr)Qf%s%B4)G~=?2Dbr1rS9Qe`h`ejPp4 z$8O&BCr8;rsgrV`bPMkFqTn3DdzKO>QW{E@Od1BN-J9h5bzZ$6zfQb|!yX(z`BnuxYXuM4twuZQE?YEAUs`uwfmU!UoD;UhUcVsE|5}BP|_!= zeENcnc<4npzKN~gp8f__S!cgQ3$B~PetPHCaF{j?)^RhpDYI_Sm_}vlNoM)lCMf3> zcIbjDb^G5EjB<&}wW3MBeco)rq(FH+pl>0oC~}c}DNg%9h={osx5kjo

    0VM1Hnz zA#cl0P{M>jLzr-`I$MTV3b3Zv(b>CUV1LnYZ0R>!4gabkwRx??^$w3+c8t)%EUVHA=1ouH?H)>QPhJlYz(oz#y zETiU)#YYV%^+Y1n68lM_E3P|`y>-*1F1<3Tj0T@wQNFwX&*$dZ+$FdBegrb(@@mS* z1I9h;hsJ`u9#8x0XvnqMqu_}M6cpk-cz^Z~pfI&Ajs$Tl^^^U^;UfB$x0&T@!l|GOo4HAEU z7qjG*{rCLKs8;7}=ztOBt@J%aM5Jx9f@BrmgfLmccrOkO`qf9Jn`T<4)FwmYgUYJA zovq4dzn8%}|I7`w?jtGb`{os|KTb^$wRqK@p|@qXu#nJ=k7`Uxau}fiYJByR1suhP zf&*z=WPH`ih}(FL2EXRX-KKA}p4?#IeDTXVHA|)9m=_mDM{;cUv7$xkpq%t|t@;>n z3iU}+@sX)yS!713U8U0Sm~=v?kb2;wm2k^*J-O*Sr81k2^_GFm|&LeNKU7TI}fGGv{%q6yaRWc{_^{9lLAEatxEz%S#dzTE{ zsom%~k>SV&voy3y+AQnmb>7@vCleNl|sSICU+F%g1VJ=Kc^ux>1T1W!rEqAE;mw5WF<#0da) zJ@{8Q%?yWwB-J7}0bap4q~6#Z#wxUWxJToRFk0IE45}kk?5K#@`B2?DH>Q-9pn0~# zqYecS=fr*Wt2qQ=?m_lWMJpWsJs(0P?bxom;@p({-Jln#_Hn znuTwYO4X;FGWU?%hW6;$?6rcmJn?HCwj;L%o~g1d_btPjrC)5MQ^wcG1|q8w)qQ+l zQ^$XoM@}7)k+~lam$^&2eICTe+NDB%D0Zs!b38Z1Pg_=5N#>b=v;Z6#5 z!9M=9;79WLIbmvlX1Zl|MlQjvUzMrd%e-^Tk;KWz0M9L3*n9&-w-ula+k&z&JK27C z?Rg3Z-Syw_jt6|)f(@EhB`BTh|N0TGc&EU~lJ32x8I=(0&Ryb;BM=xV1HdJq;TZ;X zO5K-hY9;o)Z!~T9En0A>!;H0;OGI(Uk1m zqouV8*EVSv7fLxS-rG_}QF?a`M*tLBaHmn&C&`J5^Ck09gAD+$6;Bw$8oV?TWQ_X-Xt%262<{ zOANHjn)5ZEnx{+-Tt36s!NqoUnRstFX1`Iak_7nt-%}bYLj34z{zViSFbVc9nn#-(@5dpvOPL#{GCzYbyNjM!-UU* zHBmU8%QUhKl_5x_d^78@8gB8$l%kB7RAPiWYMHNoYi=gSd8!0zGzn`RzV2hy9C9~J z%!02&ianw~iQ5Zn9+Z$FG%@{(w$Zc^H~(5408TmiGF9J&Lu{lK$Fo2LmG`r9c}8Tr z=aw>kp4ek-64x({#rKEr-}X~eA{WatHnH8H6hEZA#9_Wo*`AkK7;PX0gbFs%Y3Lr_ z4m91pf!rY>>2(b!UF^HnoJ}<{JlmDEJJ&V5JEX6p^T4}eP0u<1^!U^F%3+U|&NxLQ zF0ThU+t4XGAU$1!bC2wit(2uhx>UO|kOlb|y9Dpqqwq)D{AuZCYwToH1Ra0;(APb2 zic(QcxX>qYCrp#KvUSKbZ&Yt<-iglXArM)ssNN+H#fHeRoHv6N0o#`r4NDsGWo=8p zcfX;`JguuuXU#>qYV6%wJ{N3vmjl4ye38e}X@?ZNnUR#}LWK32Z`3XN-qvz@N!@JW zVzSUt$rZeSfDKU$P~#b?_0XoqIH4Hn+pNyQ$T_#@p-}(*T2W<{q@*q*!!rE(kiE zDwO6ffhUHjPu+j0B8d1Rm$0JYW4q>73TC9V+S$+8(T))en2$$IVsZTfck6z>`5Jr^ zH^MkGm~*&f2YfA)oruvt=lGt{ZAaVzl7jDep9CI7vdhFL0y)LSeRg-yKHSrcZ!D@> z(M(RctBAT`nQrWbN@F=2O2gw;F7ueO-E6o!oCHPMeO7o14yU^Q{Ax}>qgo_S7mPl< z*O{;IbWJ1VYKar11W1-%Pq6SaxOKl(nO?=gilX2u^^G$Q3Khj-0aE#2?(K>p@J^l+ z%GT{Cu`8UIvCf3I0Qg~QrC#QfIE$%Y%*$0tWjEW6qfbf=2QeRAC;8(ky`%57&Wi0~ zWD!@-aK^9E=ejIKHppVvsx>u-O#)kQ)2vNr=$}x~=GYFY-#m&Yfl30RqUhdvj!)>K zc7tUwQPT|7d)|qwT9OBoKsy&O{4URh^5dS;3btamrJ}4*<@iKy`_qvoCoI2lB4V+! z{m?t<{VJYGO*O1K?f5Z-ijcmM4Pf+~XY8Pr`_;p8I_&mgI7P|m?GH(iRVA+6S3z<3 zz6CFF*mD+G<+vqqS2`vU{w;2-#~IF$LMG@Xe!A^>YS>p6j6*z;y>p;jqQ_kYO~m)| z00VhJEC_3IRM&@A^^WEJR%N>J;ZXI8Bvu>BIQfDZg7&Lhp`62PS(c|}(m6P1WRABzDS zn`zE23NM@*QJd=#$6FSs`l?zK#)tMe4&k9#>(k~U()GOwlLnDR<%lp;fbU71cPba z0%M#=)+$D%_Yhpelng9B`NR^u^bLy}(Qal&&Y6UFuZMf9>%vui`Piw!VBJ#exnsYI zJ3bz_?^=BtQ2M3K9GR>G2w_!K@rjyRtI69(@;0>PEM-JUmrA5Ub|(s=w6DTmj4;pe z(PiX;!6h7RqbZu~h0MwNc09l#QbQMof8Z6Z#B=c__!3v&eHj)F!qig1S%Th<)4sLUX8;9{uuW2 z!jR!P%nsh4C5uZhrzoO^-)xG^iiq*C9|FUQSOpq!Z4qB z1E)?N&oe7E-J~F5s8YluH^DT;k8N72Si87$C4yU0$h=MEt}+d9>BI5#Z@G%{X^v=odm6A&eror-ArDsO!7ZBx$GY7YKPt9}PD)uD zU=I-uVt_E(u5?s2&UO@h;>!CWftQY5t@+ELAi8!_!w|^*dl$qIX4YwsOWqVi^Nl2E zySpBtK!0gRuwhWsgy|p_f!N6<*@{bu4|hbtFV1r8-Zs=wX-o8RXMxi+g!}C5lg0M$ zZG1qBnACm#2zlLW@2}hMWhrlBiwZuNpECPY?|tc)7r$^2qYiG+VX*Px^ItF`m>Dmtx)Dp%}hN{X?>xmBOa$eso**I0?gxA67TP8wNcb#orZI3siYA734+5 z8GEXK2FEO3P@-yy967^nsNkW#4GkDfg=3r9~usR+Vio5a)+Sem?EG2#Z4hE=i8t+mTu=N8E->;CR#frgZDFf zP9mvw<}14879S59kg9P5@EJ1+1wnAP_3d7^G@T}5swd)iCqZ{Ak^$L?;Lr{%0#<`P z3RUzsDcnMJx#&@w|24|$Axka7r5jlg-wjfN9n129)6XUPq!WI_h%UXC+np==P_;f{}Ou1 zus=-7d9l8nm`{@}G3o~|yE?DqAGtb#n?45UX20Fc#8R1F(spZBr|YaKqc# zcjuT8EpMbHn!~C2{(e(g$x~Kt&H~K0@APxI-t5gXpNVh78o$0)3+n5g&~Pmv$+eCt z0eR=@sOREV+%dGUlyd6-cIR%ooUaO|ukWvsulMtIn>fHBzDEvTJZ!{-7T!jal9Rhj z+^x5T$O>wTHRbidX}woFVEiG!)KiM4rK!5tg|5MS^2cbF2g`A_@@R>)X@0RGd7-kQ zZsF9^_a&cAr*@o0Tjj871fEXe?E9ro#nGX1mve}+uIotCf}YVg!I}Aq!{pzi*&ku9 zJLcK<`{!?>?O;@JY1$3m`_SK-Eh0;8gG7@>rAGXDu67Y}c~2ujO4r}}M<>1m7zu7& zm;xbw&8?G<6r^Zx%x)5hFm$jUM}jb~Yx=)+o|E0*VN->JqwB&7N2tg3zF#D z@mpYrC){?XGEWMZ4#+k915UJF>d|ue>u3@J!UU11yEyEk@+!?@#nZRw_xUxOd$X6U z#RAb!a?!n`L+Fe{qh}l$I|;4`l4}B1+0$k9@_BDzE05v#5#D$2n8){^S~NX=&KDW> zPe|9F?H?Wmez%FsDwAbCg*zceu5E}qJj3oEdJ&;F8&ZBt&H8j~x^5zmmt;*YCK97C z{Ou2Pzuqqc8C37@vP_sL?bkvXHTrIn!O1c8Oh^lwF-_N>QudVV3@$w@11IIaM}qqRhD4^YWb3&rK0SVR%{L z=)=Pu+V9mgcD{wK@Y5)|U0$>`j*>%*I^-Jzf&L%M_ILK2q@)n-B_27OL~#>UpLn}3 zCCu8Ue=`tN3`2hgZ1zl>`zfCD#Cv!T3xIA%&>9|<8EdWuy^FIamyICG>o`HDV^GZ7 zOzFu|bT~%eh^+bcJS4dHW_zz*Nmv_0!wL(}&uW$DJY0sa9bC45Du(`wWM`oMzcfD43b+yS@(Xw#@^m0H^fI)^kI-(>ZzkLi)O`q+L zplk(AUr;nMG6`~es_{B}2HJ&TYGoo+bT658nv2+u-Zk3}!u^KR)!-!+wF%+F?v+r$ zDS+s{ysl_2)X}wzvI9@ws_o68Gv#!?DEb&h{uR30A53P}B)gJ%F8AG`DtMy7*vE}L z+@>P)t7020cAE`&Lj(t{LHfI&StIs8=J~O_Qo$(Bv#SC2})F!{cz-<#;uk&;ebc@{~?@IztNgO5AC?Q}hzQu!R6Jpr6o-5GM*@ zkM*{GdGCi{v{d$oeF-$DSKL*uCOJZll~ec~c2Q&XsT{k8_TrKALw`l=X}<2ap1ve* zQ3*&z?2{75PO||;E8ghA73wT+My5sj3$_@vyY>a0d2m*9pg79U)*L;f%;u6%MHy}P z%x1CI+eE_&P2tWLvb{QrgJKI1Z%dX6p0_}igS{NeWmtk{!e)wjZUWIF_QE#?m{tmL zx34&o!B37IsYL57Wx~O(V!KSK#B|ZX=yi|&e%)$#Pvp=21H6>J5z!XR6N0#1!Z&P; z^Imhu+}!0SJjF_vhc3SSdFj2p(@p)|_o2MmZHj}!7F5?KM^mBtERVad#pwKf>NGW2Fu=8 z9ySBRg5o2yrWz;Nn3-I3wu_)vlfQFye4;Cg+2oemaw~FGMSz_1{i2?&AmH{-ME3XwpAkPDv}dqjDni}hnmwg*m&PoGE^sMGc(9gs3zw-4ZD`?g z`W`Kp?V?xoc^mVMz_xIr-frFc_8Ue-9LsyWf6K+gM$$evfrf zv+VdLdj$4*v-~@euE+5EEtj^X>*rk`=))obboY)0i&*D(rR$hn#bT>{q4#wi-cgQ* ztg#v3Gtsr3i{HhFg>K0K6AWM|nK7!x|2&(@#0dwzF*&Y>daVMn9UW$v3XIC8raE+H zT7wB92FU2*|780;D_-}NNc*|e$DGr zYJ55t>fEAiT{ZRN4|a~6LZY)SbBSiR9of69ZeMag6qk&lhBMMle%rwu1HhR1cSX-v z>jvJwT98u2aV;xM<-Lq;$NQq1T_*~YSI?q?0YyY+2t`8u;fkg2|G))evD?E?9V5D( ze}3zIFk1$qb{iQb?U?(&GjLd+(8@yMx|c4oMGz8hE0}^;#C30pxQimD1tXr0!!LXS z0)vlGKvYOywM#uXseB%{ykf3wv+0tKDs^aMmW?yJirj5Eh^Pf4p7H#8}eCx!C0ARt-+X!+L^%q_Q@f~aF!y$sipNVAbuiNU<)a$_F z{WYqv$taXW$)>55iT9T)v|3d?RHG3*DTv{=icu+XPr!aot{csJL6QELda3K9Aeti% z#5CLszSns|(%mEJ3dAb%@}`oPJiCt^ck7om5SVjWgMJ5q;sgy#p` zUt~bzY{J`A`57V0H$px`TtmMnDPxShWn!+$&amMTK7?A3lzqDYYr8`Xx?!UOXw=&G z?4skH%ljM`$f-zVlnW}pZ30QeyzB0rqW>}t%Z)qRDiW$Ug%*m!^N z7o}RoL+a?Ugf?}P9o3$at~o0-(Ql6il>-7-Ik`qGK%W6)I@%Jci2BBYZZ>Y8L(Q-I zYBRB~9&Y)+NHt4yNX}*gXu5yA{QyAjr(t7p+oZ0mAugxy;$62ryTuG76&(*M)>&P!)4S~5Fw`n~0FSJ0M zMjBt4H%1fGPO4?pIcw_AD22(Qfv5=RvSL{jdbAn0aJmGg;L!>0{L1X*?mK|RfI1`xdd|#C(DJDzEoOzwS?^5hfYU- z3iw^Np8@z`HgLmjKG2RdJwMZjR3J$bw!>V;!i^Hiw+OZBZOd%ql*5=$SgufOIv}h1AGu&2vlJ6^(XO9 z>w;v!Vy9x4;zSrVHvrrpz~Vz*|9p72$8o4OF)NsUp?vl$e&xds^DA)Fbpbhc$%uMl z-ymM%1B3k*JujBd&#h^uPk_xOUobX!#fV}ckb^A8=$n(UU4G@M(7Kseog*+WD!#rt zU@;Nxix=up%le0`y@>h``zfr>Zt=shu$Of(HN4kaiVe)*l+{be?`qJwN-2!k@=l+B zNn2>NF9V2QZe?UKB;<)#a$T>nR9&bX9$yg27|-N8MrYv#gV(|U$YL{82-|tZxFSp-@BQJ~XKbJFax?QsM(K|jo~sZ6 z3vMMw6VqPfy9{jA%Xgo}N6rddXqSvZ-Vry|H2Ao;jmbwtB4Dv!55#PvVA$WUc?#mE z@e>-I#uk286Hu}kx#UrZUbJd7HzhHir#W9j^p&6zE)PPF@E+JnJ~BAn*ujf7JjcyV zB78>5{-TXNY@qHSA$0lgIo+ludVP-P8e%gkxH%Fz$~w>n%smK!KWNW zL%5|BdsH)oFr%L@0m}ZHlk$Hf?&0CIkkB4^)E|+FBnum{(td zKQWL9^o>vtIbayX0!9wf7B2cQIe_LrDt&!A@z%O&Zeb8WDh_(T(@c~-yG4UPZ@^+m zM|?^BdauTeQuTBu|3T~~x}Gzy`HsWv3`>82n??ctralgE-Kz_55e#P&?0gAmxtK?z zmoW(yuk}f|^{r;xAEibb)ec1ZK$RMkUPa4v2R%73O?{`uIjf0^gFiB7B zDXanl(a2A41yzNwAWghK^;p9U-K6|&677ao45;mXA%hB!$lt9=zKJ;{S;~2kl*Nl2 zh~$|FEC9ZNgIkqO+1TO~)#v)O3M3<=F0d}z$;)>#kme-fQdtia!8#9pE zr%_c@_LHM$i}Tb0GQJC?E7bzIPtx)9j0ZHHo3Zu%@Zh_?;PL6DZ3jsWVlY*_^+yOZ zS%;<5#oa}`gK(1;(#)m4+4^E=@-*v7rG3^-u`Z05hZh$&yC$_-(~sO303cTQ>s53%oO$$ z8FcbXTy~kf&qUVCA)FxDyv`_LCw1ibt+z1gA?$f-=JhP$w==l@I40k%0L658R{{m< zU}eGNj1?v>HWHJw8p>snpPSen<6pm&JyU=Ll?nwXE)L!M0GYOIxWqdQ<;MW31F1t! zVq7>!g@|(HSBSPRYfLx}!WlLHNllhcOQZkO&V7Hg;r)LAPl&yP*aQ)~N>z*)B?xN7 zC{?w!RuNsHR_&+}RkK>VLTi?yYOB~qY3;2>%}`bI>-|@JfBF0Y_nvd_d7gV-=XGB9 zF#>$aMOyq}-91eiY;pjk+`s-@1gtj-M^J~MCh2?*>?8tvf&8cheJl#&P?PXxEBe24G@a|P!IMS-mu*heiY_GISsOh{0(d&Ox!Kx?XqxA^I2sI}a0Orj_6ePO;e&yMoVDe6t zE)QS)5n#mCK#%sF_1%Of(L0V15%rXgs1?yDi>ySR>#53APzAJzuqf^KO6BH5I!`4ps zBaU<|_}KH?uj|`IXH!jB-k$+AVJTB?K(O84DCf}1qDr&9@yo0yCqoDX6NFNL<8E%T zS6pG0-3X^tLd(0J1bEYZOhFvRE!Xl>20r%FE-N^qL#RsAx_s_XE5l}!PL5{_Zlv9> ze*4U5D`pO;)=KeI6O2~abR2J1FcXz1Ewh0cYVrEkIWs0JSr z!B9{c7Qr&?$1Nvs>B5EpLti3820OZ&nTWllD3h(O2?SIoZAdE zkuiy-3hNE8V>G~56^aTP;x_z#7aQI$S#{JDmf~T79LmRc5EIbuGX5}m%j;b|cl@R=yIJcCZ2L5NNOB@6=Ml|0!ZtV=;`LYMy(##FLe$_PY}A zQA~gNmMgXVh%>o}>mkN~^wP)TPGTssL>+mg;u{7c_iZkdPZ z+PAoz>5VG=yW=Z#+)GNwu;tz^{hn^Va&=Pgts;cRoDw*Ojf{lZ^Q$ zQyZS>g~s4Uk7Pw4ib^nVIJ@lpTJ{=eNrJ{`jd;0O=w%`r*QucU$KH zfw$T$h;2Ku9MOueZbWC|=3`lDTwmf%LAuVb#AU@qCWTECZ7OcYHg|n|<2pi3a;%?e z$ZKo*vw#WRYG|u+GLr{bF%9WTiBi*XQsC*wu3A$#n)Q7tLvIKlN;iuh(&%h47`BQX zMtA#AsL8uKSn->QKsGey`~^q_8acmX3*#)in}B(Xi&bjRRz6Ra#ptSP*XraObAK=R z_+3C??r-Kyp8Nrc{p20e8h}z%hru8@=YJ#H(k4;K3*2{@m5L>v;KenrJVhEaneXH; zb=T+%;C;k=f(D)T$n;ojSHYTHI23=XXZs@dVb!{s{ol%PP91g^Kz1J$lr4JK^*1Z` zqO53Lf?t?ryEMsnxw>sp-g%}ZVT%?ohNrG4?2V^w$p8= z*pbq{?FSI&hnG|x_ao+rgUVcJRk+)InfCgmV|sLlCcnVH{LA{dwbfbs%NzTx_J5O60xakIjxD zu0P{Kat14irQ?))PiE68*jc<7Pj}qsY7w)Vn-;kIfKPN8q37F97gH#~{faEdJULi<83LyDwoqPN#q~AA6%KO5v`!>>2M&hI%GZS za}W%#0NE)-Kd|k@{qvDXi;kkq1sl(*jF)hv3D@b6EPHh#Q~^+ePBc@T>w>r?l&MGR zPWyuka<#uu?!VNouo`_CRw+5%Ny7?r&V{!$_rp#yMm$3T%BDzOSQ$V<@PnoiUVDpD zI;?$CxKy9v409CVOGW224J8mWvsccEd#af{xD*Axd2dsu(2XAb0mBRWBpREm6@HBl z2pufFBdBqtw+4L8NuWw<0?lVha+F;=9GQ~s+3k?~cGQgv<898qMcb9F5~Ge24~Iz> zjcg)fVHaC%zf*<0z)5kSyNXm2RI2FAEsx_a^OUaL6i5-S0t#k{2|Z*B-W?$(cJKbpI5 zOw30sHeQcrdCx#KRH_Tge?fDqH--+2bE!-fmi;GIKDVAzzQDD9#k-YfVyaruEKOVl zJ8$b?W3@g;4e5~Z5aiCPlE=VdS12r%M&u$jLvi3jq2vpTd<|YpIrjecroHe$ar|SjyA>f`hZGN;Q)Z6jLc#Z ztq3aBR@s@xfPc$$@1pXS%3IAZK15^O8bL&4QDf*^vv25!X6RLRCTX5i<+pZKzFzuw z29xKPo~j5($Nl0?u|KtQpA*vQI9Cg312K<3+ocG!O5H!u&pC+sH?uma9@KcE^ztH) ze>;cxsGCKuv^pOqs-&!Sw+NBnWAN_J*6}t^j?@J{X4F%pe2Eg5tSp>FW=_~rCP062$5L7nTR!+2$5VQp`FcUS{zRc5$kxA4+y;Lr-u|rY7 z2`fU}KL~+u-U+bZ1!e3+z0(gm+#gz9Xk-z;o?y@Z{0T?TKtOg!PzrvVyJNn)Dxx{3 zGi|NJr7h$?vB0lSaNJVzQMGh!Lc~c zcv3W-QIa8FK#R+Onw0`+X0^s{a9<>UXEi;o0W9kszwydZ82&<`6*iziZF|ECG>#w8 zUg;dvyPfi&H`6FHYsbI56S3$|WQxQfY?aa1h#2-H@BHMs3xN)W&>kf^pAe*{Ymcu( z3;DcFa)(|~974*cN-brqY@N!ijG0%-a*u!gbF^XZ+2fWZ)nZ0kC`kFLb-7Th$s^?v zo-HdlY(Y;%@9t9L00v*TOiSAl_c4y8}GNb(!Lw4Xh#^Nk_>H=vL)W4n_bBIkAc4jR~Zbs5Fzr zC2i>6VFQ9+JuJ%5+ybJB3ILAz>yYFT^NKGGZyxB{KTs_wrHuD56T6y0S+?JcL^}z? zoL*=_4H@zbm;4PR05Xxm`ZkL*$0bEW}q! zVv}!%=sW{O^Af1^9$^Y!SKMNVnAAo7kyPwT(O94ltqi$Fx^DzvF}0yjnej0mwOLdP z7v4LqloW$zB*x~$v8kVpa6QC;(Nb58Ht2NVy=Q;faOj-?2j1|P-x7ARq78G8FqepQf>JJ)bPjeQ0hK6KGtb|9!6AeQ`P%n< ziPy=1JbSY!4DyhDMZfxIRhtrm<(AUCfs8%0koSViT_Zi_C3?rqF+T3r-vyjiD^bA{~M9Z?L^XU#~0RA zWxXo|c{1uAvX8til&v*|sE^P-e!B#HI~`-0ychZ#tJU!ekguHreaZA zKh}P%?Rle?>=SesVb~=y{J|o8t>bBXge+EiM92yn{G-vj4s4GeRSbJBt{E8!9%EWW z;#!?)K5!$!lu4@Cl%;Zl zB@gA#$cH?Xxu8l4SiFASdvWg@^(#HUikT8=92Xecih8!-gXq&ftR4HNd!!!gDJ}bY z%z=OsBUGOiPwNQ3MF(}>j5HxkM${DjQDys`(l~GwOwjwNfDD+xP4|;2hjqf4SJUhapw!fXXh2-y{mSPj#kmnkW zq4~ZsM$6xLn(mzbJkLRCOq_jlsU4_rxtlWTlG6A_)I;Lm{+Xa)2-iS5Rzz2<;(1k9 zqH89%DLI*??)4TTz+%GD>{$HCyG$@+t2;ko!g?1!3B7pb#&yjSXDwQTFP2mfpoP z>PphF#y=BFdG-)A+O@8E>`}cGJ7^Rv;M<(S^USkxB4qFqMN`vK^F79fwRRvhkJ^KA z%QfFN^{4NvnDgO_w=bQM&*D$LGeX!uveB$w`ksD}Z{^H{xDf0v!&tP&5(3xh6A?q} z%OC&6v~5%Dzbe*s!tHBHZv@ZOqZunE2CU z;zBne8{6?@{=HS&h@X*7#tr=X;_iWm!+z|T?foIE68jE2K)B zAPZ#Q6nQ>tO%=BlF}(BX^X&!iXphz9?#r=NejfMY)pW}7q@aG&kjC0sa_4_zu6kR@ zyR8#H5}prxH!kk={{%=1YS>C&QmI;umlkT=bNr7;Y^yRW%Oz&IxKL2*d}*e3wqEYW uo#AfGO%qSK_aBVvHz#QoQunhZ8vZJOhEo8j~nQkpvtu!!~YM~iekY4 literal 0 HcmV?d00001 diff --git a/index.html b/index.html index 9e39e46fd..36bfc148d 100644 --- a/index.html +++ b/index.html @@ -271,7 +271,11 @@

  • - Third Party Resources + Third Party Packages +
    • + +
  • + Tutorials and Resources
  • @@ -322,6 +326,10 @@ Release Notes
    • +
  • + Jobs +
    • + @@ -525,11 +533,12 @@ continued development by signing up for a paid
  • Stream
  • Machinalis
  • Rollbar
    • +
  • MicroPyramid
    • -

    Many thanks to all our wonderful sponsors, and in particular to our premium backers, Rover, Sentry, Stream, Machinalis, and Rollbar.

    +

    Many thanks to all our wonderful sponsors, and in particular to our premium backers, Rover, Sentry, Stream, Machinalis, Rollbar, and MicroPyramid.

    Requirements

    REST framework requires the following:

    @@ -665,7 +674,8 @@ urlpatterns = [
  • Browser enhancements
  • The Browsable API
  • REST, Hypermedia & HATEOAS
    • -
  • Third Party Resources
    • +
  • Third Party Packages
    • +
  • Tutorials and Resources
  • Contributing to REST framework
  • Project management
  • 3.0 Announcement
    • @@ -678,6 +688,7 @@ urlpatterns = [
  • Mozilla Grant
  • Funding
  • Release Notes
    • +
  • Jobs

    • Development

    See the Contribution guidelines for information on how to clone diff --git a/mkdocs/search_index.json b/mkdocs/search_index.json index 7b8b9a748..5b4393c92 100644 --- a/mkdocs/search_index.json +++ b/mkdocs/search_index.json @@ -2,12 +2,12 @@ "docs": [ { "location": "/", - "text": ".promo li a {\n float: left;\n width: 130px;\n height: 20px;\n text-align: center;\n margin: 10px 30px;\n padding: 150px 0 0 0;\n background-position: 0 50%;\n background-size: 130px auto;\n background-repeat: no-repeat;\n font-size: 120%;\n color: black;\n}\n.promo li {\n list-style: none;\n}\n\n\n\n\n\n \n\n\n \n\n \n\n \n\n\n \n\n \n\n \n\n\n\n\n\n\n\nNote\n: This is the documentation for the \nversion 3\n of REST framework. Documentation for \nversion 2\n is also available.\n\n\n\n\n\n\nDjango REST Framework\n\n\n\n\n\n\n\n\nDjango REST framework is a powerful and flexible toolkit for building Web APIs.\n\n\nSome reasons you might want to use REST framework:\n\n\n\n\nThe \nWeb browsable API\n is a huge usability win for your developers.\n\n\nAuthentication policies\n including packages for \nOAuth1a\n and \nOAuth2\n.\n\n\nSerialization\n that supports both \nORM\n and \nnon-ORM\n data sources.\n\n\nCustomizable all the way down - just use \nregular function-based views\n if you don't need the \nmore\n \npowerful\n \nfeatures\n.\n\n\nExtensive documentation\n, and \ngreat community support\n.\n\n\nUsed and trusted by internationally recognised companies including \nMozilla\n, \nRed Hat\n, \nHeroku\n, and \nEventbrite\n.\n\n\n\n\n\n\nFunding\n\n\nREST framework is a \ncollaboratively funded project\n. If you use\nREST framework commercially we strongly encourage you to invest in its\ncontinued development by \nsigning up for a paid plan\n.\n\n\nThe initial aim is to provide a single full-time position on REST framework.\n\nEvery single sign-up makes a significant impact towards making that possible.\n\n\n\n \nRover.com\n\n \nSentry\n\n \nStream\n\n \nMachinalis\n\n \nRollbar\n\n\n\n\n\n\n\n\nMany thanks to all our \nwonderful sponsors\n, and in particular to our premium backers, \nRover\n, \nSentry\n, \nStream\n, \nMachinalis\n, and \nRollbar\n.\n\n\n\n\nRequirements\n\n\nREST framework requires the following:\n\n\n\n\nPython (2.7, 3.2, 3.3, 3.4, 3.5)\n\n\nDjango (1.8, 1.9, 1.10)\n\n\n\n\nThe following packages are optional:\n\n\n\n\ncoreapi\n (1.32.0+) - Schema generation support.\n\n\nMarkdown\n (2.1.0+) - Markdown support for the browsable API.\n\n\ndjango-filter\n (0.9.2+) - Filtering support.\n\n\ndjango-crispy-forms\n - Improved HTML display for filtering.\n\n\ndjango-guardian\n (1.1.1+) - Object level permissions support.\n\n\n\n\nInstallation\n\n\nInstall using \npip\n, including any optional packages you want...\n\n\npip install djangorestframework\npip install markdown # Markdown support for the browsable API.\npip install django-filter # Filtering support\n\n\n\n...or clone the project from github.\n\n\ngit clone git@github.com:tomchristie/django-rest-framework.git\n\n\n\nAdd \n'rest_framework'\n to your \nINSTALLED_APPS\n setting.\n\n\nINSTALLED_APPS = (\n ...\n 'rest_framework',\n)\n\n\n\nIf you're intending to use the browsable API you'll probably also want to add REST framework's login and logout views. Add the following to your root \nurls.py\n file.\n\n\nurlpatterns = [\n ...\n url(r'^api-auth/', include('rest_framework.urls', namespace='rest_framework'))\n]\n\n\n\nNote that the URL path can be whatever you want, but you must include \n'rest_framework.urls'\n with the \n'rest_framework'\n namespace. You may leave out the namespace in Django 1.9+, and REST framework will set it for you.\n\n\nExample\n\n\nLet's take a look at a quick example of using REST framework to build a simple model-backed API.\n\n\nWe'll create a read-write API for accessing information on the users of our project.\n\n\nAny global settings for a REST framework API are kept in a single configuration dictionary named \nREST_FRAMEWORK\n. Start off by adding the following to your \nsettings.py\n module:\n\n\nREST_FRAMEWORK = {\n # Use Django's standard `django.contrib.auth` permissions,\n # or allow read-only access for unauthenticated users.\n 'DEFAULT_PERMISSION_CLASSES': [\n 'rest_framework.permissions.DjangoModelPermissionsOrAnonReadOnly'\n ]\n}\n\n\n\nDon't forget to make sure you've also added \nrest_framework\n to your \nINSTALLED_APPS\n.\n\n\nWe're ready to create our API now.\nHere's our project's root \nurls.py\n module:\n\n\nfrom django.conf.urls import url, include\nfrom django.contrib.auth.models import User\nfrom rest_framework import routers, serializers, viewsets\n\n# Serializers define the API representation.\nclass UserSerializer(serializers.HyperlinkedModelSerializer):\n class Meta:\n model = User\n fields = ('url', 'username', 'email', 'is_staff')\n\n# ViewSets define the view behavior.\nclass UserViewSet(viewsets.ModelViewSet):\n queryset = User.objects.all()\n serializer_class = UserSerializer\n\n# Routers provide an easy way of automatically determining the URL conf.\nrouter = routers.DefaultRouter()\nrouter.register(r'users', UserViewSet)\n\n# Wire up our API using automatic URL routing.\n# Additionally, we include login URLs for the browsable API.\nurlpatterns = [\n url(r'^', include(router.urls)),\n url(r'^api-auth/', include('rest_framework.urls', namespace='rest_framework'))\n]\n\n\n\nYou can now open the API in your browser at \nhttp://127.0.0.1:8000/\n, and view your new 'users' API. If you use the login control in the top right corner you'll also be able to add, create and delete users from the system.\n\n\nQuickstart\n\n\nCan't wait to get started? The \nquickstart guide\n is the fastest way to get up and running, and building APIs with REST framework.\n\n\nTutorial\n\n\nThe tutorial will walk you through the building blocks that make up REST framework. It'll take a little while to get through, but it'll give you a comprehensive understanding of how everything fits together, and is highly recommended reading.\n\n\n\n\n1 - Serialization\n\n\n2 - Requests \n Responses\n\n\n3 - Class-based views\n\n\n4 - Authentication \n permissions\n\n\n5 - Relationships \n hyperlinked APIs\n\n\n6 - Viewsets \n routers\n\n\n7 - Schemas \n client libraries\n\n\n\n\nThere is a live example API of the finished tutorial API for testing purposes, \navailable here\n.\n\n\nAPI Guide\n\n\nThe API guide is your complete reference manual to all the functionality provided by REST framework.\n\n\n\n\nRequests\n\n\nResponses\n\n\nViews\n\n\nGeneric views\n\n\nViewsets\n\n\nRouters\n\n\nParsers\n\n\nRenderers\n\n\nSerializers\n\n\nSerializer fields\n\n\nSerializer relations\n\n\nValidators\n\n\nAuthentication\n\n\nPermissions\n\n\nThrottling\n\n\nFiltering\n\n\nPagination\n\n\nVersioning\n\n\nContent negotiation\n\n\nMetadata\n\n\nSchemas\n\n\nFormat suffixes\n\n\nReturning URLs\n\n\nExceptions\n\n\nStatus codes\n\n\nTesting\n\n\nSettings\n\n\n\n\nTopics\n\n\nGeneral guides to using REST framework.\n\n\n\n\nDocumenting your API\n\n\nAPI Clients\n\n\nInternationalization\n\n\nAJAX, CSRF \n CORS\n\n\nHTML \n Forms\n\n\nBrowser enhancements\n\n\nThe Browsable API\n\n\nREST, Hypermedia \n HATEOAS\n\n\nThird Party Resources\n\n\nContributing to REST framework\n\n\nProject management\n\n\n3.0 Announcement\n\n\n3.1 Announcement\n\n\n3.2 Announcement\n\n\n3.3 Announcement\n\n\n3.4 Announcement\n\n\n3.5 Announcement\n\n\nKickstarter Announcement\n\n\nMozilla Grant\n\n\nFunding\n\n\nRelease Notes\n\n\n\n\nDevelopment\n\n\nSee the \nContribution guidelines\n for information on how to clone\nthe repository, run the test suite and contribute changes back to REST\nFramework.\n\n\nSupport\n\n\nFor support please see the \nREST framework discussion group\n, try the \n#restframework\n channel on \nirc.freenode.net\n, search \nthe IRC archives\n, or raise a question on \nStack Overflow\n, making sure to include the \n'django-rest-framework'\n tag.\n\n\nFor priority support please sign up for a \nprofessional or premium sponsorship plan\n.\n\n\nFor updates on REST framework development, you may also want to follow \nthe author\n on Twitter.\n\n\nFollow @_tomchristie\n\n\n!function(d,s,id){var js,fjs=d.getElementsByTagName(s)[0];if(!d.getElementById(id)){js=d.createElement(s);js.id=id;js.src=\"//platform.twitter.com/widgets.js\";fjs.parentNode.insertBefore(js,fjs);}}(document,\"script\",\"twitter-wjs\");\n\n\nSecurity\n\n\nIf you believe you\u2019ve found something in Django REST framework which has security implications, please \ndo not raise the issue in a public forum\n.\n\n\nSend a description of the issue via email to \nrest-framework-security@googlegroups.com\n. The project maintainers will then work with you to resolve any issues where required, prior to any public disclosure.\n\n\nLicense\n\n\nCopyright (c) 2011-2016, Tom Christie\nAll rights reserved.\n\n\nRedistribution and use in source and binary forms, with or without\nmodification, are permitted provided that the following conditions are met:\n\n\nRedistributions of source code must retain the above copyright notice, this\nlist of conditions and the following disclaimer.\nRedistributions in binary form must reproduce the above copyright notice, this\nlist of conditions and the following disclaimer in the documentation and/or\nother materials provided with the distribution.\n\n\nTHIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS \"AS IS\" AND\nANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED\nWARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE\nDISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE\nFOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL\nDAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR\nSERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER\nCAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,\nOR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE\nOF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.", + "text": ".promo li a {\n float: left;\n width: 130px;\n height: 20px;\n text-align: center;\n margin: 10px 30px;\n padding: 150px 0 0 0;\n background-position: 0 50%;\n background-size: 130px auto;\n background-repeat: no-repeat;\n font-size: 120%;\n color: black;\n}\n.promo li {\n list-style: none;\n}\n\n\n\n\n\n \n\n\n \n\n \n\n \n\n\n \n\n \n\n \n\n\n\n\n\n\n\nNote\n: This is the documentation for the \nversion 3\n of REST framework. Documentation for \nversion 2\n is also available.\n\n\n\n\n\n\nDjango REST Framework\n\n\n\n\n\n\n\n\nDjango REST framework is a powerful and flexible toolkit for building Web APIs.\n\n\nSome reasons you might want to use REST framework:\n\n\n\n\nThe \nWeb browsable API\n is a huge usability win for your developers.\n\n\nAuthentication policies\n including packages for \nOAuth1a\n and \nOAuth2\n.\n\n\nSerialization\n that supports both \nORM\n and \nnon-ORM\n data sources.\n\n\nCustomizable all the way down - just use \nregular function-based views\n if you don't need the \nmore\n \npowerful\n \nfeatures\n.\n\n\nExtensive documentation\n, and \ngreat community support\n.\n\n\nUsed and trusted by internationally recognised companies including \nMozilla\n, \nRed Hat\n, \nHeroku\n, and \nEventbrite\n.\n\n\n\n\n\n\nFunding\n\n\nREST framework is a \ncollaboratively funded project\n. If you use\nREST framework commercially we strongly encourage you to invest in its\ncontinued development by \nsigning up for a paid plan\n.\n\n\nThe initial aim is to provide a single full-time position on REST framework.\n\nEvery single sign-up makes a significant impact towards making that possible.\n\n\n\n \nRover.com\n\n \nSentry\n\n \nStream\n\n \nMachinalis\n\n \nRollbar\n\n \nMicroPyramid\n\n\n\n\n\n\n\n\nMany thanks to all our \nwonderful sponsors\n, and in particular to our premium backers, \nRover\n, \nSentry\n, \nStream\n, \nMachinalis\n, \nRollbar\n, and \nMicroPyramid\n.\n\n\n\n\nRequirements\n\n\nREST framework requires the following:\n\n\n\n\nPython (2.7, 3.2, 3.3, 3.4, 3.5)\n\n\nDjango (1.8, 1.9, 1.10)\n\n\n\n\nThe following packages are optional:\n\n\n\n\ncoreapi\n (1.32.0+) - Schema generation support.\n\n\nMarkdown\n (2.1.0+) - Markdown support for the browsable API.\n\n\ndjango-filter\n (0.9.2+) - Filtering support.\n\n\ndjango-crispy-forms\n - Improved HTML display for filtering.\n\n\ndjango-guardian\n (1.1.1+) - Object level permissions support.\n\n\n\n\nInstallation\n\n\nInstall using \npip\n, including any optional packages you want...\n\n\npip install djangorestframework\npip install markdown # Markdown support for the browsable API.\npip install django-filter # Filtering support\n\n\n\n...or clone the project from github.\n\n\ngit clone git@github.com:tomchristie/django-rest-framework.git\n\n\n\nAdd \n'rest_framework'\n to your \nINSTALLED_APPS\n setting.\n\n\nINSTALLED_APPS = (\n ...\n 'rest_framework',\n)\n\n\n\nIf you're intending to use the browsable API you'll probably also want to add REST framework's login and logout views. Add the following to your root \nurls.py\n file.\n\n\nurlpatterns = [\n ...\n url(r'^api-auth/', include('rest_framework.urls', namespace='rest_framework'))\n]\n\n\n\nNote that the URL path can be whatever you want, but you must include \n'rest_framework.urls'\n with the \n'rest_framework'\n namespace. You may leave out the namespace in Django 1.9+, and REST framework will set it for you.\n\n\nExample\n\n\nLet's take a look at a quick example of using REST framework to build a simple model-backed API.\n\n\nWe'll create a read-write API for accessing information on the users of our project.\n\n\nAny global settings for a REST framework API are kept in a single configuration dictionary named \nREST_FRAMEWORK\n. Start off by adding the following to your \nsettings.py\n module:\n\n\nREST_FRAMEWORK = {\n # Use Django's standard `django.contrib.auth` permissions,\n # or allow read-only access for unauthenticated users.\n 'DEFAULT_PERMISSION_CLASSES': [\n 'rest_framework.permissions.DjangoModelPermissionsOrAnonReadOnly'\n ]\n}\n\n\n\nDon't forget to make sure you've also added \nrest_framework\n to your \nINSTALLED_APPS\n.\n\n\nWe're ready to create our API now.\nHere's our project's root \nurls.py\n module:\n\n\nfrom django.conf.urls import url, include\nfrom django.contrib.auth.models import User\nfrom rest_framework import routers, serializers, viewsets\n\n# Serializers define the API representation.\nclass UserSerializer(serializers.HyperlinkedModelSerializer):\n class Meta:\n model = User\n fields = ('url', 'username', 'email', 'is_staff')\n\n# ViewSets define the view behavior.\nclass UserViewSet(viewsets.ModelViewSet):\n queryset = User.objects.all()\n serializer_class = UserSerializer\n\n# Routers provide an easy way of automatically determining the URL conf.\nrouter = routers.DefaultRouter()\nrouter.register(r'users', UserViewSet)\n\n# Wire up our API using automatic URL routing.\n# Additionally, we include login URLs for the browsable API.\nurlpatterns = [\n url(r'^', include(router.urls)),\n url(r'^api-auth/', include('rest_framework.urls', namespace='rest_framework'))\n]\n\n\n\nYou can now open the API in your browser at \nhttp://127.0.0.1:8000/\n, and view your new 'users' API. If you use the login control in the top right corner you'll also be able to add, create and delete users from the system.\n\n\nQuickstart\n\n\nCan't wait to get started? The \nquickstart guide\n is the fastest way to get up and running, and building APIs with REST framework.\n\n\nTutorial\n\n\nThe tutorial will walk you through the building blocks that make up REST framework. It'll take a little while to get through, but it'll give you a comprehensive understanding of how everything fits together, and is highly recommended reading.\n\n\n\n\n1 - Serialization\n\n\n2 - Requests \n Responses\n\n\n3 - Class-based views\n\n\n4 - Authentication \n permissions\n\n\n5 - Relationships \n hyperlinked APIs\n\n\n6 - Viewsets \n routers\n\n\n7 - Schemas \n client libraries\n\n\n\n\nThere is a live example API of the finished tutorial API for testing purposes, \navailable here\n.\n\n\nAPI Guide\n\n\nThe API guide is your complete reference manual to all the functionality provided by REST framework.\n\n\n\n\nRequests\n\n\nResponses\n\n\nViews\n\n\nGeneric views\n\n\nViewsets\n\n\nRouters\n\n\nParsers\n\n\nRenderers\n\n\nSerializers\n\n\nSerializer fields\n\n\nSerializer relations\n\n\nValidators\n\n\nAuthentication\n\n\nPermissions\n\n\nThrottling\n\n\nFiltering\n\n\nPagination\n\n\nVersioning\n\n\nContent negotiation\n\n\nMetadata\n\n\nSchemas\n\n\nFormat suffixes\n\n\nReturning URLs\n\n\nExceptions\n\n\nStatus codes\n\n\nTesting\n\n\nSettings\n\n\n\n\nTopics\n\n\nGeneral guides to using REST framework.\n\n\n\n\nDocumenting your API\n\n\nAPI Clients\n\n\nInternationalization\n\n\nAJAX, CSRF \n CORS\n\n\nHTML \n Forms\n\n\nBrowser enhancements\n\n\nThe Browsable API\n\n\nREST, Hypermedia \n HATEOAS\n\n\nThird Party Packages\n\n\nTutorials and Resources\n\n\nContributing to REST framework\n\n\nProject management\n\n\n3.0 Announcement\n\n\n3.1 Announcement\n\n\n3.2 Announcement\n\n\n3.3 Announcement\n\n\n3.4 Announcement\n\n\n3.5 Announcement\n\n\nKickstarter Announcement\n\n\nMozilla Grant\n\n\nFunding\n\n\nRelease Notes\n\n\nJobs\n\n\n\n\nDevelopment\n\n\nSee the \nContribution guidelines\n for information on how to clone\nthe repository, run the test suite and contribute changes back to REST\nFramework.\n\n\nSupport\n\n\nFor support please see the \nREST framework discussion group\n, try the \n#restframework\n channel on \nirc.freenode.net\n, search \nthe IRC archives\n, or raise a question on \nStack Overflow\n, making sure to include the \n'django-rest-framework'\n tag.\n\n\nFor priority support please sign up for a \nprofessional or premium sponsorship plan\n.\n\n\nFor updates on REST framework development, you may also want to follow \nthe author\n on Twitter.\n\n\nFollow @_tomchristie\n\n\n!function(d,s,id){var js,fjs=d.getElementsByTagName(s)[0];if(!d.getElementById(id)){js=d.createElement(s);js.id=id;js.src=\"//platform.twitter.com/widgets.js\";fjs.parentNode.insertBefore(js,fjs);}}(document,\"script\",\"twitter-wjs\");\n\n\nSecurity\n\n\nIf you believe you\u2019ve found something in Django REST framework which has security implications, please \ndo not raise the issue in a public forum\n.\n\n\nSend a description of the issue via email to \nrest-framework-security@googlegroups.com\n. The project maintainers will then work with you to resolve any issues where required, prior to any public disclosure.\n\n\nLicense\n\n\nCopyright (c) 2011-2016, Tom Christie\nAll rights reserved.\n\n\nRedistribution and use in source and binary forms, with or without\nmodification, are permitted provided that the following conditions are met:\n\n\nRedistributions of source code must retain the above copyright notice, this\nlist of conditions and the following disclaimer.\nRedistributions in binary form must reproduce the above copyright notice, this\nlist of conditions and the following disclaimer in the documentation and/or\nother materials provided with the distribution.\n\n\nTHIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS \"AS IS\" AND\nANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED\nWARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE\nDISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE\nFOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL\nDAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR\nSERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER\nCAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,\nOR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE\nOF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.", "title": "Home" }, { "location": "/#funding", - "text": "REST framework is a collaboratively funded project . If you use\nREST framework commercially we strongly encourage you to invest in its\ncontinued development by signing up for a paid plan . The initial aim is to provide a single full-time position on REST framework. Every single sign-up makes a significant impact towards making that possible. \n Rover.com \n Sentry \n Stream \n Machinalis \n Rollbar Many thanks to all our wonderful sponsors , and in particular to our premium backers, Rover , Sentry , Stream , Machinalis , and Rollbar .", + "text": "REST framework is a collaboratively funded project . If you use\nREST framework commercially we strongly encourage you to invest in its\ncontinued development by signing up for a paid plan . The initial aim is to provide a single full-time position on REST framework. Every single sign-up makes a significant impact towards making that possible. \n Rover.com \n Sentry \n Stream \n Machinalis \n Rollbar \n MicroPyramid Many thanks to all our wonderful sponsors , and in particular to our premium backers, Rover , Sentry , Stream , Machinalis , Rollbar , and MicroPyramid .", "title": "Funding" }, { @@ -42,7 +42,7 @@ }, { "location": "/#topics", - "text": "General guides to using REST framework. Documenting your API API Clients Internationalization AJAX, CSRF CORS HTML Forms Browser enhancements The Browsable API REST, Hypermedia HATEOAS Third Party Resources Contributing to REST framework Project management 3.0 Announcement 3.1 Announcement 3.2 Announcement 3.3 Announcement 3.4 Announcement 3.5 Announcement Kickstarter Announcement Mozilla Grant Funding Release Notes", + "text": "General guides to using REST framework. Documenting your API API Clients Internationalization AJAX, CSRF CORS HTML Forms Browser enhancements The Browsable API REST, Hypermedia HATEOAS Third Party Packages Tutorials and Resources Contributing to REST framework Project management 3.0 Announcement 3.1 Announcement 3.2 Announcement 3.3 Announcement 3.4 Announcement 3.5 Announcement Kickstarter Announcement Mozilla Grant Funding Release Notes Jobs", "title": "Topics" }, { @@ -1337,7 +1337,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 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\nfrom django.utils.six import BytesIO\nfrom rest_framework.parsers import JSONParser\n\nstream = 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 \nupdate()\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_\nfield_name\n methods to your \nSerializer\n subclass. These are similar to the \n.clean_\nfield_name\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_\nfield_name\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 \nfield_name\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 \nValidationError\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'] \n 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 \nupdate()\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\nIt is possible that a third party package, providing automatic support some kinds of automatic writable nested representations may be released alongside the 3.1 release.\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\n serializer = AccountSerializer()\n\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\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-\ninstance and id-\ndata 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 id = serializers.IntegerField(required=False)\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 \nValidationError\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 ValidationError({\n 'score': 'This field is required.'\n })\n if not player_name:\n raise ValidationError({\n 'player_name': 'This field is required.'\n })\n if len(player_name) \n 10:\n raise 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, deserialization or validation 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\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. Typically the \nerrors\n argument here will be a dictionary mapping field names to error messages.\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):\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.keys())\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\n class Meta:\n\n model = User\n\n fields = ('id', 'username', 'email')\n\n\n\n print UserSerializer(user)\n{'id': 2, 'username': 'jonwatts', 'email': 'jon@example.com'}\n\n\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\nA new interface for controlling this behavior is currently planned for REST framework 3.1.\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 \nform\n submissions per the (inactive) \nHTML JSON Form specification\n. The serializer facilitates processing of arbitrarily nested JSON structures within HTML. For example, \ninput name=\"items[0][id]\" value=\"5\"\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.", + "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 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\nfrom django.utils.six import BytesIO\nfrom rest_framework.parsers import JSONParser\n\nstream = 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 \nupdate()\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_\nfield_name\n methods to your \nSerializer\n subclass. These are similar to the \n.clean_\nfield_name\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_\nfield_name\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 \nfield_name\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 \nValidationError\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'] \n 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 \nupdate()\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\nIt is possible that a third party package, providing automatic support some kinds of automatic writable nested representations may be released alongside the 3.1 release.\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\n serializer = AccountSerializer()\n\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\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-\ninstance and id-\ndata 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 id = serializers.IntegerField(required=False)\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 \nValidationError\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 ValidationError({\n 'score': 'This field is required.'\n })\n if not player_name:\n raise ValidationError({\n 'player_name': 'This field is required.'\n })\n if len(player_name) \n 10:\n raise 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, deserialization or validation 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\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. Typically the \nerrors\n argument here will be a dictionary mapping field names to error messages.\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):\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.keys())\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\n class Meta:\n\n model = User\n\n fields = ('id', 'username', 'email')\n\n\n\n print UserSerializer(user)\n{'id': 2, 'username': 'jonwatts', 'email': 'jon@example.com'}\n\n\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 \nform\n submissions per the (inactive) \nHTML JSON Form specification\n. The serializer facilitates processing of arbitrarily nested JSON structures within HTML. For example, \ninput name=\"items[0][id]\" value=\"5\"\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" }, { @@ -1662,7 +1662,7 @@ }, { "location": "/api-guide/serializers/#customizing-the-default-fields", - "text": "REST framework 2 provided an API to allow developers to override how a ModelSerializer class would automatically generate the default set of fields. This API included the .get_field() , .get_pk_field() and other methods. Because 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. A new interface for controlling this behavior is currently planned for REST framework 3.1.", + "text": "REST framework 2 provided an API to allow developers to override how a ModelSerializer class would automatically generate the default set of fields. This API included the .get_field() , .get_pk_field() and other methods. Because 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.", "title": "Customizing the default fields" }, { @@ -1730,9 +1730,14 @@ "text": "djangorestframework-queryfields allows API clients to specify which fields will be sent in the response via inclusion/exclusion query parameters.", "title": "QueryFields" }, + { + "location": "/api-guide/serializers/#drf-writable-nested", + "text": "The drf-writable-nested package provides writable nested model serializer which allows to create/update models with nested related data.", + "title": "DRF Writable Nested" + }, { "location": "/api-guide/fields/", - "text": "Serializer fields\n\n\n\n\nEach field in a Form class is responsible not only for validating data, but also for \"cleaning\" it \n normalizing it to a consistent format.\n\n\n \nDjango documentation\n\n\n\n\nSerializer fields handle converting between primitive values and internal datatypes. They also deal with validating input values, as well as retrieving and setting the values from their parent objects.\n\n\n\n\nNote:\n The serializer fields are declared in \nfields.py\n, but by convention you should import them using \nfrom rest_framework import serializers\n and refer to fields as \nserializers.\nFieldName\n.\n\n\n\n\nCore arguments\n\n\nEach serializer field class constructor takes at least these arguments. Some Field classes take additional, field-specific arguments, but the following should always be accepted:\n\n\nread_only\n\n\nRead-only fields are included in the API output, but should not be included in the input during create or update operations. Any 'read_only' fields that are incorrectly included in the serializer input will be ignored.\n\n\nSet this to \nTrue\n to ensure that the field is used when serializing a representation, but is not used when creating or updating an instance during deserialization.\n\n\nDefaults to \nFalse\n\n\nwrite_only\n\n\nSet this to \nTrue\n to ensure that the field may be used when updating or creating an instance, but is not included when serializing the representation.\n\n\nDefaults to \nFalse\n\n\nrequired\n\n\nNormally an error will be raised if a field is not supplied during deserialization.\nSet to false if this field is not required to be present during deserialization.\n\n\nSetting this to \nFalse\n also allows the object attribute or dictionary key to be omitted from output when serializing the instance. If the key is not present it will simply not be included in the output representation.\n\n\nDefaults to \nTrue\n.\n\n\nallow_null\n\n\nNormally an error will be raised if \nNone\n is passed to a serializer field. Set this keyword argument to \nTrue\n if \nNone\n should be considered a valid value.\n\n\nDefaults to \nFalse\n\n\ndefault\n\n\nIf set, this gives the default value that will be used for the field if no input value is supplied. If not set the default behaviour is to not populate the attribute at all.\n\n\nThe \ndefault\n is not applied during partial update operations. In the partial update case only fields that are provided in the incoming data will have a validated value returned.\n\n\nMay be set to a function or other callable, in which case the value will be evaluated each time it is used. When called, it will receive no arguments. If the callable has a \nset_context\n method, that will be called each time before getting the value with the field instance as only argument. This works the same way as for \nvalidators\n.\n\n\nNote that setting a \ndefault\n value implies that the field is not required. Including both the \ndefault\n and \nrequired\n keyword arguments is invalid and will raise an error.\n\n\nsource\n\n\nThe name of the attribute that will be used to populate the field. May be a method that only takes a \nself\n argument, such as \nURLField(source='get_absolute_url')\n, or may use dotted notation to traverse attributes, such as \nEmailField(source='user.email')\n.\n\n\nThe value \nsource='*'\n has a special meaning, and is used to indicate that the entire object should be passed through to the field. This can be useful for creating nested representations, or for fields which require access to the complete object in order to determine the output representation.\n\n\nDefaults to the name of the field.\n\n\nvalidators\n\n\nA list of validator functions which should be applied to the incoming field input, and which either raise a validation error or simply return. Validator functions should typically raise \nserializers.ValidationError\n, but Django's built-in \nValidationError\n is also supported for compatibility with validators defined in the Django codebase or third party Django packages.\n\n\nerror_messages\n\n\nA dictionary of error codes to error messages.\n\n\nlabel\n\n\nA short text string that may be used as the name of the field in HTML form fields or other descriptive elements.\n\n\nhelp_text\n\n\nA text string that may be used as a description of the field in HTML form fields or other descriptive elements.\n\n\ninitial\n\n\nA value that should be used for pre-populating the value of HTML form fields. You may pass a callable to it, just as\nyou may do with any regular Django \nField\n:\n\n\nimport datetime\nfrom rest_framework import serializers\nclass ExampleSerializer(serializers.Serializer):\n day = serializers.DateField(initial=datetime.date.today)\n\n\n\nstyle\n\n\nA dictionary of key-value pairs that can be used to control how renderers should render the field.\n\n\nTwo examples here are \n'input_type'\n and \n'base_template'\n:\n\n\n# Use \ninput type=\"password\"\n for the input.\npassword = serializers.CharField(\n style={'input_type': 'password'}\n)\n\n# Use a radio input instead of a select input.\ncolor_channel = serializers.ChoiceField(\n choices=['red', 'green', 'blue'],\n style={'base_template': 'radio.html'}\n)\n\n\n\nFor more details see the \nHTML \n Forms\n documentation.\n\n\n\n\nBoolean fields\n\n\nBooleanField\n\n\nA boolean representation.\n\n\nWhen using HTML encoded form input be aware that omitting a value will always be treated as setting a field to \nFalse\n, even if it has a \ndefault=True\n option specified. This is because HTML checkbox inputs represent the unchecked state by omitting the value, so REST framework treats omission as if it is an empty checkbox input.\n\n\nCorresponds to \ndjango.db.models.fields.BooleanField\n.\n\n\nSignature:\n \nBooleanField()\n\n\nNullBooleanField\n\n\nA boolean representation that also accepts \nNone\n as a valid value.\n\n\nCorresponds to \ndjango.db.models.fields.NullBooleanField\n.\n\n\nSignature:\n \nNullBooleanField()\n\n\n\n\nString fields\n\n\nCharField\n\n\nA text representation. Optionally validates the text to be shorter than \nmax_length\n and longer than \nmin_length\n.\n\n\nCorresponds to \ndjango.db.models.fields.CharField\n or \ndjango.db.models.fields.TextField\n.\n\n\nSignature:\n \nCharField(max_length=None, min_length=None, allow_blank=False, trim_whitespace=True)\n\n\n\n\nmax_length\n - Validates that the input contains no more than this number of characters.\n\n\nmin_length\n - Validates that the input contains no fewer than this number of characters.\n\n\nallow_blank\n - If set to \nTrue\n then the empty string should be considered a valid value. If set to \nFalse\n then the empty string is considered invalid and will raise a validation error. Defaults to \nFalse\n.\n\n\ntrim_whitespace\n - If set to \nTrue\n then leading and trailing whitespace is trimmed. Defaults to \nTrue\n.\n\n\n\n\nThe \nallow_null\n option is also available for string fields, although its usage is discouraged in favor of \nallow_blank\n. It is valid to set both \nallow_blank=True\n and \nallow_null=True\n, but doing so means that there will be two differing types of empty value permissible for string representations, which can lead to data inconsistencies and subtle application bugs.\n\n\nEmailField\n\n\nA text representation, validates the text to be a valid e-mail address.\n\n\nCorresponds to \ndjango.db.models.fields.EmailField\n\n\nSignature:\n \nEmailField(max_length=None, min_length=None, allow_blank=False)\n\n\nRegexField\n\n\nA text representation, that validates the given value matches against a certain regular expression.\n\n\nCorresponds to \ndjango.forms.fields.RegexField\n.\n\n\nSignature:\n \nRegexField(regex, max_length=None, min_length=None, allow_blank=False)\n\n\nThe mandatory \nregex\n argument may either be a string, or a compiled python regular expression object.\n\n\nUses Django's \ndjango.core.validators.RegexValidator\n for validation.\n\n\nSlugField\n\n\nA \nRegexField\n that validates the input against the pattern \n[a-zA-Z0-9_-]+\n.\n\n\nCorresponds to \ndjango.db.models.fields.SlugField\n.\n\n\nSignature:\n \nSlugField(max_length=50, min_length=None, allow_blank=False)\n\n\nURLField\n\n\nA \nRegexField\n that validates the input against a URL matching pattern. Expects fully qualified URLs of the form \nhttp://\nhost\n/\npath\n.\n\n\nCorresponds to \ndjango.db.models.fields.URLField\n. Uses Django's \ndjango.core.validators.URLValidator\n for validation.\n\n\nSignature:\n \nURLField(max_length=200, min_length=None, allow_blank=False)\n\n\nUUIDField\n\n\nA field that ensures the input is a valid UUID string. The \nto_internal_value\n method will return a \nuuid.UUID\n instance. On output the field will return a string in the canonical hyphenated format, for example:\n\n\n\"de305d54-75b4-431b-adb2-eb6b9e546013\"\n\n\n\nSignature:\n \nUUIDField(format='hex_verbose')\n\n\n\n\nformat\n: Determines the representation format of the uuid value\n\n\n'hex_verbose'\n - The cannoncical hex representation, including hyphens: \n\"5ce0e9a5-5ffa-654b-cee0-1238041fb31a\"\n\n\n'hex'\n - The compact hex representation of the UUID, not including hyphens: \n\"5ce0e9a55ffa654bcee01238041fb31a\"\n\n\n'int'\n - A 128 bit integer representation of the UUID: \n\"123456789012312313134124512351145145114\"\n\n\n'urn'\n - RFC 4122 URN representation of the UUID: \n\"urn:uuid:5ce0e9a5-5ffa-654b-cee0-1238041fb31a\"\n\n Changing the \nformat\n parameters only affects representation values. All formats are accepted by \nto_internal_value\n\n\n\n\n\n\n\n\nFilePathField\n\n\nA field whose choices are limited to the filenames in a certain directory on the filesystem\n\n\nCorresponds to \ndjango.forms.fields.FilePathField\n.\n\n\nSignature:\n \nFilePathField(path, match=None, recursive=False, allow_files=True, allow_folders=False, required=None, **kwargs)\n\n\n\n\npath\n - The absolute filesystem path to a directory from which this FilePathField should get its choice.\n\n\nmatch\n - A regular expression, as a string, that FilePathField will use to filter filenames.\n\n\nrecursive\n - Specifies whether all subdirectories of path should be included. Default is \nFalse\n.\n\n\nallow_files\n - Specifies whether files in the specified location should be included. Default is \nTrue\n. Either this or \nallow_folders\n must be \nTrue\n.\n\n\nallow_folders\n - Specifies whether folders in the specified location should be included. Default is \nFalse\n. Either this or \nallow_files\n must be \nTrue\n.\n\n\n\n\nIPAddressField\n\n\nA field that ensures the input is a valid IPv4 or IPv6 string.\n\n\nCorresponds to \ndjango.forms.fields.IPAddressField\n and \ndjango.forms.fields.GenericIPAddressField\n.\n\n\nSignature\n: \nIPAddressField(protocol='both', unpack_ipv4=False, **options)\n\n\n\n\nprotocol\n Limits valid inputs to the specified protocol. Accepted values are 'both' (default), 'IPv4' or 'IPv6'. Matching is case insensitive.\n\n\nunpack_ipv4\n Unpacks IPv4 mapped addresses like ::ffff:192.0.2.1. If this option is enabled that address would be unpacked to 192.0.2.1. Default is disabled. Can only be used when protocol is set to 'both'.\n\n\n\n\n\n\nNumeric fields\n\n\nIntegerField\n\n\nAn integer representation.\n\n\nCorresponds to \ndjango.db.models.fields.IntegerField\n, \ndjango.db.models.fields.SmallIntegerField\n, \ndjango.db.models.fields.PositiveIntegerField\n and \ndjango.db.models.fields.PositiveSmallIntegerField\n.\n\n\nSignature\n: \nIntegerField(max_value=None, min_value=None)\n\n\n\n\nmax_value\n Validate that the number provided is no greater than this value.\n\n\nmin_value\n Validate that the number provided is no less than this value.\n\n\n\n\nFloatField\n\n\nA floating point representation.\n\n\nCorresponds to \ndjango.db.models.fields.FloatField\n.\n\n\nSignature\n: \nFloatField(max_value=None, min_value=None)\n\n\n\n\nmax_value\n Validate that the number provided is no greater than this value.\n\n\nmin_value\n Validate that the number provided is no less than this value.\n\n\n\n\nDecimalField\n\n\nA decimal representation, represented in Python by a \nDecimal\n instance.\n\n\nCorresponds to \ndjango.db.models.fields.DecimalField\n.\n\n\nSignature\n: \nDecimalField(max_digits, decimal_places, coerce_to_string=None, max_value=None, min_value=None)\n\n\n\n\nmax_digits\n The maximum number of digits allowed in the number. It must be either \nNone\n or an integer greater than or equal to \ndecimal_places\n.\n\n\ndecimal_places\n The number of decimal places to store with the number.\n\n\ncoerce_to_string\n Set to \nTrue\n if string values should be returned for the representation, or \nFalse\n if \nDecimal\n objects should be returned. Defaults to the same value as the \nCOERCE_DECIMAL_TO_STRING\n settings key, which will be \nTrue\n unless overridden. If \nDecimal\n objects are returned by the serializer, then the final output format will be determined by the renderer. Note that setting \nlocalize\n will force the value to \nTrue\n.\n\n\nmax_value\n Validate that the number provided is no greater than this value.\n\n\nmin_value\n Validate that the number provided is no less than this value.\n\n\nlocalize\n Set to \nTrue\n to enable localization of input and output based on the current locale. This will also force \ncoerce_to_string\n to \nTrue\n. Defaults to \nFalse\n. Note that data formatting is enabled if you have set \nUSE_L10N=True\n in your settings file.\n\n\n\n\nExample usage\n\n\nTo validate numbers up to 999 with a resolution of 2 decimal places, you would use:\n\n\nserializers.DecimalField(max_digits=5, decimal_places=2)\n\n\n\nAnd to validate numbers up to anything less than one billion with a resolution of 10 decimal places:\n\n\nserializers.DecimalField(max_digits=19, decimal_places=10)\n\n\n\nThis field also takes an optional argument, \ncoerce_to_string\n. If set to \nTrue\n the representation will be output as a string. If set to \nFalse\n the representation will be left as a \nDecimal\n instance and the final representation will be determined by the renderer.\n\n\nIf unset, this will default to the same value as the \nCOERCE_DECIMAL_TO_STRING\n setting, which is \nTrue\n unless set otherwise.\n\n\n\n\nDate and time fields\n\n\nDateTimeField\n\n\nA date and time representation.\n\n\nCorresponds to \ndjango.db.models.fields.DateTimeField\n.\n\n\nSignature:\n \nDateTimeField(format=api_settings.DATETIME_FORMAT, input_formats=None)\n\n\n\n\nformat\n - A string representing the output format. If not specified, this defaults to the same value as the \nDATETIME_FORMAT\n settings key, which will be \n'iso-8601'\n unless set. Setting to a format string indicates that \nto_representation\n return values should be coerced to string output. Format strings are described below. Setting this value to \nNone\n indicates that Python \ndatetime\n objects should be returned by \nto_representation\n. In this case the datetime encoding will be determined by the renderer.\n\n\ninput_formats\n - A list of strings representing the input formats which may be used to parse the date. If not specified, the \nDATETIME_INPUT_FORMATS\n setting will be used, which defaults to \n['iso-8601']\n.\n\n\n\n\nDateTimeField\n format strings.\n\n\nFormat strings may either be \nPython strftime formats\n which explicitly specify the format, or the special string \n'iso-8601'\n, which indicates that \nISO 8601\n style datetimes should be used. (eg \n'2013-01-29T12:34:56.000000Z'\n)\n\n\nWhen a value of \nNone\n is used for the format \ndatetime\n objects will be returned by \nto_representation\n and the final output representation will determined by the renderer class.\n\n\nIn the case of JSON this means the default datetime representation uses the \nECMA 262 date time string specification\n. This is a subset of ISO 8601 which uses millisecond precision, and includes the 'Z' suffix for the UTC timezone, for example: \n2013-01-29T12:34:56.123Z\n.\n\n\nauto_now_add\n model fields.\nauto_now\n and \n\n\nWhen using \nModelSerializer\n or \nHyperlinkedModelSerializer\n, note that any model fields with \nauto_now=True\n or \nauto_now_add=True\n will use serializer fields that are \nread_only=True\n by default.\n\n\nIf you want to override this behavior, you'll need to declare the \nDateTimeField\n explicitly on the serializer. For example:\n\n\nclass CommentSerializer(serializers.ModelSerializer):\n created = serializers.DateTimeField()\n\n class Meta:\n model = Comment\n\n\n\nDateField\n\n\nA date representation.\n\n\nCorresponds to \ndjango.db.models.fields.DateField\n\n\nSignature:\n \nDateField(format=api_settings.DATE_FORMAT, input_formats=None)\n\n\n\n\nformat\n - A string representing the output format. If not specified, this defaults to the same value as the \nDATE_FORMAT\n settings key, which will be \n'iso-8601'\n unless set. Setting to a format string indicates that \nto_representation\n return values should be coerced to string output. Format strings are described below. Setting this value to \nNone\n indicates that Python \ndate\n objects should be returned by \nto_representation\n. In this case the date encoding will be determined by the renderer.\n\n\ninput_formats\n - A list of strings representing the input formats which may be used to parse the date. If not specified, the \nDATE_INPUT_FORMATS\n setting will be used, which defaults to \n['iso-8601']\n.\n\n\n\n\nDateField\n format strings\n\n\nFormat strings may either be \nPython strftime formats\n which explicitly specify the format, or the special string \n'iso-8601'\n, which indicates that \nISO 8601\n style dates should be used. (eg \n'2013-01-29'\n)\n\n\nTimeField\n\n\nA time representation.\n\n\nCorresponds to \ndjango.db.models.fields.TimeField\n\n\nSignature:\n \nTimeField(format=api_settings.TIME_FORMAT, input_formats=None)\n\n\n\n\nformat\n - A string representing the output format. If not specified, this defaults to the same value as the \nTIME_FORMAT\n settings key, which will be \n'iso-8601'\n unless set. Setting to a format string indicates that \nto_representation\n return values should be coerced to string output. Format strings are described below. Setting this value to \nNone\n indicates that Python \ntime\n objects should be returned by \nto_representation\n. In this case the time encoding will be determined by the renderer.\n\n\ninput_formats\n - A list of strings representing the input formats which may be used to parse the date. If not specified, the \nTIME_INPUT_FORMATS\n setting will be used, which defaults to \n['iso-8601']\n.\n\n\n\n\nTimeField\n format strings\n\n\nFormat strings may either be \nPython strftime formats\n which explicitly specify the format, or the special string \n'iso-8601'\n, which indicates that \nISO 8601\n style times should be used. (eg \n'12:34:56.000000'\n)\n\n\nDurationField\n\n\nA Duration representation.\nCorresponds to \ndjango.db.models.fields.DurationField\n\n\nThe \nvalidated_data\n for these fields will contain a \ndatetime.timedelta\n instance.\nThe representation is a string following this format \n'[DD] [HH:[MM:]]ss[.uuuuuu]'\n.\n\n\nNote:\n This field is only available with Django versions \n= 1.8.\n\n\nSignature:\n \nDurationField()\n\n\n\n\nChoice selection fields\n\n\nChoiceField\n\n\nA field that can accept a value out of a limited set of choices.\n\n\nUsed by \nModelSerializer\n to automatically generate fields if the corresponding model field includes a \nchoices=\u2026\n argument.\n\n\nSignature:\n \nChoiceField(choices)\n\n\n\n\nchoices\n - A list of valid values, or a list of \n(key, display_name)\n tuples.\n\n\nallow_blank\n - If set to \nTrue\n then the empty string should be considered a valid value. If set to \nFalse\n then the empty string is considered invalid and will raise a validation error. Defaults to \nFalse\n.\n\n\nhtml_cutoff\n - If set this will be the maximum number of choices that will be displayed by a HTML select drop down. Can be used to ensure that automatically generated ChoiceFields with very large possible selections do not prevent a template from rendering. Defaults to \nNone\n.\n\n\nhtml_cutoff_text\n - If set this will display a textual indicator if the maximum number of items have been cutoff in an HTML select drop down. Defaults to \n\"More than {count} items\u2026\"\n\n\n\n\nBoth the \nallow_blank\n and \nallow_null\n are valid options on \nChoiceField\n, although it is highly recommended that you only use one and not both. \nallow_blank\n should be preferred for textual choices, and \nallow_null\n should be preferred for numeric or other non-textual choices.\n\n\nMultipleChoiceField\n\n\nA field that can accept a set of zero, one or many values, chosen from a limited set of choices. Takes a single mandatory argument. \nto_internal_value\n returns a \nset\n containing the selected values.\n\n\nSignature:\n \nMultipleChoiceField(choices)\n\n\n\n\nchoices\n - A list of valid values, or a list of \n(key, display_name)\n tuples.\n\n\nallow_blank\n - If set to \nTrue\n then the empty string should be considered a valid value. If set to \nFalse\n then the empty string is considered invalid and will raise a validation error. Defaults to \nFalse\n.\n\n\nhtml_cutoff\n - If set this will be the maximum number of choices that will be displayed by a HTML select drop down. Can be used to ensure that automatically generated ChoiceFields with very large possible selections do not prevent a template from rendering. Defaults to \nNone\n.\n\n\nhtml_cutoff_text\n - If set this will display a textual indicator if the maximum number of items have been cutoff in an HTML select drop down. Defaults to \n\"More than {count} items\u2026\"\n\n\n\n\nAs with \nChoiceField\n, both the \nallow_blank\n and \nallow_null\n options are valid, although it is highly recommended that you only use one and not both. \nallow_blank\n should be preferred for textual choices, and \nallow_null\n should be preferred for numeric or other non-textual choices.\n\n\n\n\nFile upload fields\n\n\nParsers and file uploads.\n\n\nThe \nFileField\n and \nImageField\n classes are only suitable for use with \nMultiPartParser\n or \nFileUploadParser\n. Most parsers, such as e.g. JSON don't support file uploads.\nDjango's regular \nFILE_UPLOAD_HANDLERS\n are used for handling uploaded files.\n\n\nFileField\n\n\nA file representation. Performs Django's standard FileField validation.\n\n\nCorresponds to \ndjango.forms.fields.FileField\n.\n\n\nSignature:\n \nFileField(max_length=None, allow_empty_file=False, use_url=UPLOADED_FILES_USE_URL)\n\n\n\n\nmax_length\n - Designates the maximum length for the file name.\n\n\nallow_empty_file\n - Designates if empty files are allowed.\n\n\nuse_url\n - If set to \nTrue\n then URL string values will be used for the output representation. If set to \nFalse\n then filename string values will be used for the output representation. Defaults to the value of the \nUPLOADED_FILES_USE_URL\n settings key, which is \nTrue\n unless set otherwise.\n\n\n\n\nImageField\n\n\nAn image representation. Validates the uploaded file content as matching a known image format.\n\n\nCorresponds to \ndjango.forms.fields.ImageField\n.\n\n\nSignature:\n \nImageField(max_length=None, allow_empty_file=False, use_url=UPLOADED_FILES_USE_URL)\n\n\n\n\nmax_length\n - Designates the maximum length for the file name.\n\n\nallow_empty_file\n - Designates if empty files are allowed.\n\n\nuse_url\n - If set to \nTrue\n then URL string values will be used for the output representation. If set to \nFalse\n then filename string values will be used for the output representation. Defaults to the value of the \nUPLOADED_FILES_USE_URL\n settings key, which is \nTrue\n unless set otherwise.\n\n\n\n\nRequires either the \nPillow\n package or \nPIL\n package. The \nPillow\n package is recommended, as \nPIL\n is no longer actively maintained.\n\n\n\n\nComposite fields\n\n\nListField\n\n\nA field class that validates a list of objects.\n\n\nSignature\n: \nListField(child, min_length=None, max_length=None)\n\n\n\n\nchild\n - A field instance that should be used for validating the objects in the list. If this argument is not provided then objects in the list will not be validated.\n\n\nmin_length\n - Validates that the list contains no fewer than this number of elements.\n\n\nmax_length\n - Validates that the list contains no more than this number of elements.\n\n\n\n\nFor example, to validate a list of integers you might use something like the following:\n\n\nscores = serializers.ListField(\n child=serializers.IntegerField(min_value=0, max_value=100)\n)\n\n\n\nThe \nListField\n class also supports a declarative style that allows you to write reusable list field classes.\n\n\nclass StringListField(serializers.ListField):\n child = serializers.CharField()\n\n\n\nWe can now reuse our custom \nStringListField\n class throughout our application, without having to provide a \nchild\n argument to it.\n\n\nDictField\n\n\nA field class that validates a dictionary of objects. The keys in \nDictField\n are always assumed to be string values.\n\n\nSignature\n: \nDictField(child)\n\n\n\n\nchild\n - A field instance that should be used for validating the values in the dictionary. If this argument is not provided then values in the mapping will not be validated.\n\n\n\n\nFor example, to create a field that validates a mapping of strings to strings, you would write something like this:\n\n\ndocument = DictField(child=CharField())\n\n\n\nYou can also use the declarative style, as with \nListField\n. For example:\n\n\nclass DocumentField(DictField):\n child = CharField()\n\n\n\nJSONField\n\n\nA field class that validates that the incoming data structure consists of valid JSON primitives. In its alternate binary mode, it will represent and validate JSON-encoded binary strings.\n\n\nSignature\n: \nJSONField(binary)\n\n\n\n\nbinary\n - If set to \nTrue\n then the field will output and validate a JSON encoded string, rather than a primitive data structure. Defaults to \nFalse\n.\n\n\n\n\n\n\nMiscellaneous fields\n\n\nReadOnlyField\n\n\nA field class that simply returns the value of the field without modification.\n\n\nThis field is used by default with \nModelSerializer\n when including field names that relate to an attribute rather than a model field.\n\n\nSignature\n: \nReadOnlyField()\n\n\nFor example, if \nhas_expired\n was a property on the \nAccount\n model, then the following serializer would automatically generate it as a \nReadOnlyField\n:\n\n\nclass AccountSerializer(serializers.ModelSerializer):\n class Meta:\n model = Account\n fields = ('id', 'account_name', 'has_expired')\n\n\n\nHiddenField\n\n\nA field class that does not take a value based on user input, but instead takes its value from a default value or callable.\n\n\nSignature\n: \nHiddenField()\n\n\nFor example, to include a field that always provides the current time as part of the serializer validated data, you would use the following:\n\n\nmodified = serializers.HiddenField(default=timezone.now)\n\n\n\nThe \nHiddenField\n class is usually only needed if you have some validation that needs to run based on some pre-provided field values, but you do not want to expose all of those fields to the end user.\n\n\nFor further examples on \nHiddenField\n see the \nvalidators\n documentation.\n\n\nModelField\n\n\nA generic field that can be tied to any arbitrary model field. The \nModelField\n class delegates the task of serialization/deserialization to its associated model field. This field can be used to create serializer fields for custom model fields, without having to create a new custom serializer field.\n\n\nThis field is used by \nModelSerializer\n to correspond to custom model field classes.\n\n\nSignature:\n \nModelField(model_field=\nDjango ModelField instance\n)\n\n\nThe \nModelField\n class is generally intended for internal use, but can be used by your API if needed. In order to properly instantiate a \nModelField\n, it must be passed a field that is attached to an instantiated model. For example: \nModelField(model_field=MyModel()._meta.get_field('custom_field'))\n\n\nSerializerMethodField\n\n\nThis is a read-only field. It gets its value by calling a method on the serializer class it is attached to. It can be used to add any sort of data to the serialized representation of your object.\n\n\nSignature\n: \nSerializerMethodField(method_name=None)\n\n\n\n\nmethod_name\n - The name of the method on the serializer to be called. If not included this defaults to \nget_\nfield_name\n.\n\n\n\n\nThe serializer method referred to by the \nmethod_name\n argument should accept a single argument (in addition to \nself\n), which is the object being serialized. It should return whatever you want to be included in the serialized representation of the object. For example:\n\n\nfrom django.contrib.auth.models import User\nfrom django.utils.timezone import now\nfrom rest_framework import serializers\n\nclass UserSerializer(serializers.ModelSerializer):\n days_since_joined = serializers.SerializerMethodField()\n\n class Meta:\n model = User\n\n def get_days_since_joined(self, obj):\n return (now() - obj.date_joined).days\n\n\n\n\n\nCustom fields\n\n\nIf you want to create a custom field, you'll need to subclass \nField\n and then override either one or both of the \n.to_representation()\n and \n.to_internal_value()\n methods. These two methods are used to convert between the initial datatype, and a primitive, serializable datatype. Primitive datatypes will typically be any of a number, string, boolean, \ndate\n/\ntime\n/\ndatetime\n or \nNone\n. They may also be any list or dictionary like object that only contains other primitive objects. Other types might be supported, depending on the renderer that you are using.\n\n\nThe \n.to_representation()\n method is called to convert the initial datatype into a primitive, serializable datatype.\n\n\nThe \nto_internal_value()\n method is called to restore a primitive datatype into its internal python representation. This method should raise a \nserializers.ValidationError\n if the data is invalid.\n\n\nNote that the \nWritableField\n class that was present in version 2.x no longer exists. You should subclass \nField\n and override \nto_internal_value()\n if the field supports data input.\n\n\nExamples\n\n\nLet's look at an example of serializing a class that represents an RGB color value:\n\n\nclass Color(object):\n \"\"\"\n A color represented in the RGB colorspace.\n \"\"\"\n def __init__(self, red, green, blue):\n assert(red \n= 0 and green \n= 0 and blue \n= 0)\n assert(red \n 256 and green \n 256 and blue \n 256)\n self.red, self.green, self.blue = red, green, blue\n\nclass ColorField(serializers.Field):\n \"\"\"\n Color objects are serialized into 'rgb(#, #, #)' notation.\n \"\"\"\n def to_representation(self, obj):\n return \"rgb(%d, %d, %d)\" % (obj.red, obj.green, obj.blue)\n\n def to_internal_value(self, data):\n data = data.strip('rgb(').rstrip(')')\n red, green, blue = [int(col) for col in data.split(',')]\n return Color(red, green, blue)\n\n\n\nBy default field values are treated as mapping to an attribute on the object. If you need to customize how the field value is accessed and set you need to override \n.get_attribute()\n and/or \n.get_value()\n.\n\n\nAs an example, let's create a field that can be used to represent the class name of the object being serialized:\n\n\nclass ClassNameField(serializers.Field):\n def get_attribute(self, obj):\n # We pass the object instance onto `to_representation`,\n # not just the field attribute.\n return obj\n\n def to_representation(self, obj):\n \"\"\"\n Serialize the object's class name.\n \"\"\"\n return obj.__class__.__name__\n\n\n\nRaising validation errors\n\n\nOur \nColorField\n class above currently does not perform any data validation.\nTo indicate invalid data, we should raise a \nserializers.ValidationError\n, like so:\n\n\ndef to_internal_value(self, data):\n if not isinstance(data, six.text_type):\n msg = 'Incorrect type. Expected a string, but got %s'\n raise ValidationError(msg % type(data).__name__)\n\n if not re.match(r'^rgb\\([0-9]+,[0-9]+,[0-9]+\\)$', data):\n raise ValidationError('Incorrect format. Expected `rgb(#,#,#)`.')\n\n data = data.strip('rgb(').rstrip(')')\n red, green, blue = [int(col) for col in data.split(',')]\n\n if any([col \n 255 or col \n 0 for col in (red, green, blue)]):\n raise ValidationError('Value out of range. Must be between 0 and 255.')\n\n return Color(red, green, blue)\n\n\n\nThe \n.fail()\n method is a shortcut for raising \nValidationError\n that takes a message string from the \nerror_messages\n dictionary. For example:\n\n\ndefault_error_messages = {\n 'incorrect_type': 'Incorrect type. Expected a string, but got {input_type}',\n 'incorrect_format': 'Incorrect format. Expected `rgb(#,#,#)`.',\n 'out_of_range': 'Value out of range. Must be between 0 and 255.'\n}\n\ndef to_internal_value(self, data):\n if not isinstance(data, six.text_type):\n self.fail('incorrect_type', input_type=type(data).__name__)\n\n if not re.match(r'^rgb\\([0-9]+,[0-9]+,[0-9]+\\)$', data):\n self.fail('incorrect_format')\n\n data = data.strip('rgb(').rstrip(')')\n red, green, blue = [int(col) for col in data.split(',')]\n\n if any([col \n 255 or col \n 0 for col in (red, green, blue)]):\n self.fail('out_of_range')\n\n return Color(red, green, blue)\n\n\n\nThis style keeps you error messages more cleanly separated from your code, and should be preferred.\n\n\nThird party packages\n\n\nThe following third party packages are also available.\n\n\nDRF Compound Fields\n\n\nThe \ndrf-compound-fields\n package provides \"compound\" serializer fields, such as lists of simple values, which can be described by other fields rather than serializers with the \nmany=True\n option. Also provided are fields for typed dictionaries and values that can be either a specific type or a list of items of that type.\n\n\nDRF Extra Fields\n\n\nThe \ndrf-extra-fields\n package provides extra serializer fields for REST framework, including \nBase64ImageField\n and \nPointField\n classes.\n\n\ndjangrestframework-recursive\n\n\nthe \ndjangorestframework-recursive\n package provides a \nRecursiveField\n for serializing and deserializing recursive structures\n\n\ndjango-rest-framework-gis\n\n\nThe \ndjango-rest-framework-gis\n package provides geographic addons for django rest framework like a \nGeometryField\n field and a GeoJSON serializer.\n\n\ndjango-rest-framework-hstore\n\n\nThe \ndjango-rest-framework-hstore\n package provides an \nHStoreField\n to support \ndjango-hstore\n \nDictionaryField\n model field.", + "text": "Serializer fields\n\n\n\n\nEach field in a Form class is responsible not only for validating data, but also for \"cleaning\" it \n normalizing it to a consistent format.\n\n\n \nDjango documentation\n\n\n\n\nSerializer fields handle converting between primitive values and internal datatypes. They also deal with validating input values, as well as retrieving and setting the values from their parent objects.\n\n\n\n\nNote:\n The serializer fields are declared in \nfields.py\n, but by convention you should import them using \nfrom rest_framework import serializers\n and refer to fields as \nserializers.\nFieldName\n.\n\n\n\n\nCore arguments\n\n\nEach serializer field class constructor takes at least these arguments. Some Field classes take additional, field-specific arguments, but the following should always be accepted:\n\n\nread_only\n\n\nRead-only fields are included in the API output, but should not be included in the input during create or update operations. Any 'read_only' fields that are incorrectly included in the serializer input will be ignored.\n\n\nSet this to \nTrue\n to ensure that the field is used when serializing a representation, but is not used when creating or updating an instance during deserialization.\n\n\nDefaults to \nFalse\n\n\nwrite_only\n\n\nSet this to \nTrue\n to ensure that the field may be used when updating or creating an instance, but is not included when serializing the representation.\n\n\nDefaults to \nFalse\n\n\nrequired\n\n\nNormally an error will be raised if a field is not supplied during deserialization.\nSet to false if this field is not required to be present during deserialization.\n\n\nSetting this to \nFalse\n also allows the object attribute or dictionary key to be omitted from output when serializing the instance. If the key is not present it will simply not be included in the output representation.\n\n\nDefaults to \nTrue\n.\n\n\nallow_null\n\n\nNormally an error will be raised if \nNone\n is passed to a serializer field. Set this keyword argument to \nTrue\n if \nNone\n should be considered a valid value.\n\n\nDefaults to \nFalse\n\n\ndefault\n\n\nIf set, this gives the default value that will be used for the field if no input value is supplied. If not set the default behaviour is to not populate the attribute at all.\n\n\nThe \ndefault\n is not applied during partial update operations. In the partial update case only fields that are provided in the incoming data will have a validated value returned.\n\n\nMay be set to a function or other callable, in which case the value will be evaluated each time it is used. When called, it will receive no arguments. If the callable has a \nset_context\n method, that will be called each time before getting the value with the field instance as only argument. This works the same way as for \nvalidators\n.\n\n\nNote that setting a \ndefault\n value implies that the field is not required. Including both the \ndefault\n and \nrequired\n keyword arguments is invalid and will raise an error.\n\n\nsource\n\n\nThe name of the attribute that will be used to populate the field. May be a method that only takes a \nself\n argument, such as \nURLField(source='get_absolute_url')\n, or may use dotted notation to traverse attributes, such as \nEmailField(source='user.email')\n.\n\n\nThe value \nsource='*'\n has a special meaning, and is used to indicate that the entire object should be passed through to the field. This can be useful for creating nested representations, or for fields which require access to the complete object in order to determine the output representation.\n\n\nDefaults to the name of the field.\n\n\nvalidators\n\n\nA list of validator functions which should be applied to the incoming field input, and which either raise a validation error or simply return. Validator functions should typically raise \nserializers.ValidationError\n, but Django's built-in \nValidationError\n is also supported for compatibility with validators defined in the Django codebase or third party Django packages.\n\n\nerror_messages\n\n\nA dictionary of error codes to error messages.\n\n\nlabel\n\n\nA short text string that may be used as the name of the field in HTML form fields or other descriptive elements.\n\n\nhelp_text\n\n\nA text string that may be used as a description of the field in HTML form fields or other descriptive elements.\n\n\ninitial\n\n\nA value that should be used for pre-populating the value of HTML form fields. You may pass a callable to it, just as\nyou may do with any regular Django \nField\n:\n\n\nimport datetime\nfrom rest_framework import serializers\nclass ExampleSerializer(serializers.Serializer):\n day = serializers.DateField(initial=datetime.date.today)\n\n\n\nstyle\n\n\nA dictionary of key-value pairs that can be used to control how renderers should render the field.\n\n\nTwo examples here are \n'input_type'\n and \n'base_template'\n:\n\n\n# Use \ninput type=\"password\"\n for the input.\npassword = serializers.CharField(\n style={'input_type': 'password'}\n)\n\n# Use a radio input instead of a select input.\ncolor_channel = serializers.ChoiceField(\n choices=['red', 'green', 'blue'],\n style={'base_template': 'radio.html'}\n)\n\n\n\nFor more details see the \nHTML \n Forms\n documentation.\n\n\n\n\nBoolean fields\n\n\nBooleanField\n\n\nA boolean representation.\n\n\nWhen using HTML encoded form input be aware that omitting a value will always be treated as setting a field to \nFalse\n, even if it has a \ndefault=True\n option specified. This is because HTML checkbox inputs represent the unchecked state by omitting the value, so REST framework treats omission as if it is an empty checkbox input.\n\n\nCorresponds to \ndjango.db.models.fields.BooleanField\n.\n\n\nSignature:\n \nBooleanField()\n\n\nNullBooleanField\n\n\nA boolean representation that also accepts \nNone\n as a valid value.\n\n\nCorresponds to \ndjango.db.models.fields.NullBooleanField\n.\n\n\nSignature:\n \nNullBooleanField()\n\n\n\n\nString fields\n\n\nCharField\n\n\nA text representation. Optionally validates the text to be shorter than \nmax_length\n and longer than \nmin_length\n.\n\n\nCorresponds to \ndjango.db.models.fields.CharField\n or \ndjango.db.models.fields.TextField\n.\n\n\nSignature:\n \nCharField(max_length=None, min_length=None, allow_blank=False, trim_whitespace=True)\n\n\n\n\nmax_length\n - Validates that the input contains no more than this number of characters.\n\n\nmin_length\n - Validates that the input contains no fewer than this number of characters.\n\n\nallow_blank\n - If set to \nTrue\n then the empty string should be considered a valid value. If set to \nFalse\n then the empty string is considered invalid and will raise a validation error. Defaults to \nFalse\n.\n\n\ntrim_whitespace\n - If set to \nTrue\n then leading and trailing whitespace is trimmed. Defaults to \nTrue\n.\n\n\n\n\nThe \nallow_null\n option is also available for string fields, although its usage is discouraged in favor of \nallow_blank\n. It is valid to set both \nallow_blank=True\n and \nallow_null=True\n, but doing so means that there will be two differing types of empty value permissible for string representations, which can lead to data inconsistencies and subtle application bugs.\n\n\nEmailField\n\n\nA text representation, validates the text to be a valid e-mail address.\n\n\nCorresponds to \ndjango.db.models.fields.EmailField\n\n\nSignature:\n \nEmailField(max_length=None, min_length=None, allow_blank=False)\n\n\nRegexField\n\n\nA text representation, that validates the given value matches against a certain regular expression.\n\n\nCorresponds to \ndjango.forms.fields.RegexField\n.\n\n\nSignature:\n \nRegexField(regex, max_length=None, min_length=None, allow_blank=False)\n\n\nThe mandatory \nregex\n argument may either be a string, or a compiled python regular expression object.\n\n\nUses Django's \ndjango.core.validators.RegexValidator\n for validation.\n\n\nSlugField\n\n\nA \nRegexField\n that validates the input against the pattern \n[a-zA-Z0-9_-]+\n.\n\n\nCorresponds to \ndjango.db.models.fields.SlugField\n.\n\n\nSignature:\n \nSlugField(max_length=50, min_length=None, allow_blank=False)\n\n\nURLField\n\n\nA \nRegexField\n that validates the input against a URL matching pattern. Expects fully qualified URLs of the form \nhttp://\nhost\n/\npath\n.\n\n\nCorresponds to \ndjango.db.models.fields.URLField\n. Uses Django's \ndjango.core.validators.URLValidator\n for validation.\n\n\nSignature:\n \nURLField(max_length=200, min_length=None, allow_blank=False)\n\n\nUUIDField\n\n\nA field that ensures the input is a valid UUID string. The \nto_internal_value\n method will return a \nuuid.UUID\n instance. On output the field will return a string in the canonical hyphenated format, for example:\n\n\n\"de305d54-75b4-431b-adb2-eb6b9e546013\"\n\n\n\nSignature:\n \nUUIDField(format='hex_verbose')\n\n\n\n\nformat\n: Determines the representation format of the uuid value\n\n\n'hex_verbose'\n - The cannoncical hex representation, including hyphens: \n\"5ce0e9a5-5ffa-654b-cee0-1238041fb31a\"\n\n\n'hex'\n - The compact hex representation of the UUID, not including hyphens: \n\"5ce0e9a55ffa654bcee01238041fb31a\"\n\n\n'int'\n - A 128 bit integer representation of the UUID: \n\"123456789012312313134124512351145145114\"\n\n\n'urn'\n - RFC 4122 URN representation of the UUID: \n\"urn:uuid:5ce0e9a5-5ffa-654b-cee0-1238041fb31a\"\n\n Changing the \nformat\n parameters only affects representation values. All formats are accepted by \nto_internal_value\n\n\n\n\n\n\n\n\nFilePathField\n\n\nA field whose choices are limited to the filenames in a certain directory on the filesystem\n\n\nCorresponds to \ndjango.forms.fields.FilePathField\n.\n\n\nSignature:\n \nFilePathField(path, match=None, recursive=False, allow_files=True, allow_folders=False, required=None, **kwargs)\n\n\n\n\npath\n - The absolute filesystem path to a directory from which this FilePathField should get its choice.\n\n\nmatch\n - A regular expression, as a string, that FilePathField will use to filter filenames.\n\n\nrecursive\n - Specifies whether all subdirectories of path should be included. Default is \nFalse\n.\n\n\nallow_files\n - Specifies whether files in the specified location should be included. Default is \nTrue\n. Either this or \nallow_folders\n must be \nTrue\n.\n\n\nallow_folders\n - Specifies whether folders in the specified location should be included. Default is \nFalse\n. Either this or \nallow_files\n must be \nTrue\n.\n\n\n\n\nIPAddressField\n\n\nA field that ensures the input is a valid IPv4 or IPv6 string.\n\n\nCorresponds to \ndjango.forms.fields.IPAddressField\n and \ndjango.forms.fields.GenericIPAddressField\n.\n\n\nSignature\n: \nIPAddressField(protocol='both', unpack_ipv4=False, **options)\n\n\n\n\nprotocol\n Limits valid inputs to the specified protocol. Accepted values are 'both' (default), 'IPv4' or 'IPv6'. Matching is case insensitive.\n\n\nunpack_ipv4\n Unpacks IPv4 mapped addresses like ::ffff:192.0.2.1. If this option is enabled that address would be unpacked to 192.0.2.1. Default is disabled. Can only be used when protocol is set to 'both'.\n\n\n\n\n\n\nNumeric fields\n\n\nIntegerField\n\n\nAn integer representation.\n\n\nCorresponds to \ndjango.db.models.fields.IntegerField\n, \ndjango.db.models.fields.SmallIntegerField\n, \ndjango.db.models.fields.PositiveIntegerField\n and \ndjango.db.models.fields.PositiveSmallIntegerField\n.\n\n\nSignature\n: \nIntegerField(max_value=None, min_value=None)\n\n\n\n\nmax_value\n Validate that the number provided is no greater than this value.\n\n\nmin_value\n Validate that the number provided is no less than this value.\n\n\n\n\nFloatField\n\n\nA floating point representation.\n\n\nCorresponds to \ndjango.db.models.fields.FloatField\n.\n\n\nSignature\n: \nFloatField(max_value=None, min_value=None)\n\n\n\n\nmax_value\n Validate that the number provided is no greater than this value.\n\n\nmin_value\n Validate that the number provided is no less than this value.\n\n\n\n\nDecimalField\n\n\nA decimal representation, represented in Python by a \nDecimal\n instance.\n\n\nCorresponds to \ndjango.db.models.fields.DecimalField\n.\n\n\nSignature\n: \nDecimalField(max_digits, decimal_places, coerce_to_string=None, max_value=None, min_value=None)\n\n\n\n\nmax_digits\n The maximum number of digits allowed in the number. It must be either \nNone\n or an integer greater than or equal to \ndecimal_places\n.\n\n\ndecimal_places\n The number of decimal places to store with the number.\n\n\ncoerce_to_string\n Set to \nTrue\n if string values should be returned for the representation, or \nFalse\n if \nDecimal\n objects should be returned. Defaults to the same value as the \nCOERCE_DECIMAL_TO_STRING\n settings key, which will be \nTrue\n unless overridden. If \nDecimal\n objects are returned by the serializer, then the final output format will be determined by the renderer. Note that setting \nlocalize\n will force the value to \nTrue\n.\n\n\nmax_value\n Validate that the number provided is no greater than this value.\n\n\nmin_value\n Validate that the number provided is no less than this value.\n\n\nlocalize\n Set to \nTrue\n to enable localization of input and output based on the current locale. This will also force \ncoerce_to_string\n to \nTrue\n. Defaults to \nFalse\n. Note that data formatting is enabled if you have set \nUSE_L10N=True\n in your settings file.\n\n\n\n\nExample usage\n\n\nTo validate numbers up to 999 with a resolution of 2 decimal places, you would use:\n\n\nserializers.DecimalField(max_digits=5, decimal_places=2)\n\n\n\nAnd to validate numbers up to anything less than one billion with a resolution of 10 decimal places:\n\n\nserializers.DecimalField(max_digits=19, decimal_places=10)\n\n\n\nThis field also takes an optional argument, \ncoerce_to_string\n. If set to \nTrue\n the representation will be output as a string. If set to \nFalse\n the representation will be left as a \nDecimal\n instance and the final representation will be determined by the renderer.\n\n\nIf unset, this will default to the same value as the \nCOERCE_DECIMAL_TO_STRING\n setting, which is \nTrue\n unless set otherwise.\n\n\n\n\nDate and time fields\n\n\nDateTimeField\n\n\nA date and time representation.\n\n\nCorresponds to \ndjango.db.models.fields.DateTimeField\n.\n\n\nSignature:\n \nDateTimeField(format=api_settings.DATETIME_FORMAT, input_formats=None)\n\n\n\n\nformat\n - A string representing the output format. If not specified, this defaults to the same value as the \nDATETIME_FORMAT\n settings key, which will be \n'iso-8601'\n unless set. Setting to a format string indicates that \nto_representation\n return values should be coerced to string output. Format strings are described below. Setting this value to \nNone\n indicates that Python \ndatetime\n objects should be returned by \nto_representation\n. In this case the datetime encoding will be determined by the renderer.\n\n\ninput_formats\n - A list of strings representing the input formats which may be used to parse the date. If not specified, the \nDATETIME_INPUT_FORMATS\n setting will be used, which defaults to \n['iso-8601']\n.\n\n\n\n\nDateTimeField\n format strings.\n\n\nFormat strings may either be \nPython strftime formats\n which explicitly specify the format, or the special string \n'iso-8601'\n, which indicates that \nISO 8601\n style datetimes should be used. (eg \n'2013-01-29T12:34:56.000000Z'\n)\n\n\nWhen a value of \nNone\n is used for the format \ndatetime\n objects will be returned by \nto_representation\n and the final output representation will determined by the renderer class.\n\n\nauto_now_add\n model fields.\nauto_now\n and \n\n\nWhen using \nModelSerializer\n or \nHyperlinkedModelSerializer\n, note that any model fields with \nauto_now=True\n or \nauto_now_add=True\n will use serializer fields that are \nread_only=True\n by default.\n\n\nIf you want to override this behavior, you'll need to declare the \nDateTimeField\n explicitly on the serializer. For example:\n\n\nclass CommentSerializer(serializers.ModelSerializer):\n created = serializers.DateTimeField()\n\n class Meta:\n model = Comment\n\n\n\nDateField\n\n\nA date representation.\n\n\nCorresponds to \ndjango.db.models.fields.DateField\n\n\nSignature:\n \nDateField(format=api_settings.DATE_FORMAT, input_formats=None)\n\n\n\n\nformat\n - A string representing the output format. If not specified, this defaults to the same value as the \nDATE_FORMAT\n settings key, which will be \n'iso-8601'\n unless set. Setting to a format string indicates that \nto_representation\n return values should be coerced to string output. Format strings are described below. Setting this value to \nNone\n indicates that Python \ndate\n objects should be returned by \nto_representation\n. In this case the date encoding will be determined by the renderer.\n\n\ninput_formats\n - A list of strings representing the input formats which may be used to parse the date. If not specified, the \nDATE_INPUT_FORMATS\n setting will be used, which defaults to \n['iso-8601']\n.\n\n\n\n\nDateField\n format strings\n\n\nFormat strings may either be \nPython strftime formats\n which explicitly specify the format, or the special string \n'iso-8601'\n, which indicates that \nISO 8601\n style dates should be used. (eg \n'2013-01-29'\n)\n\n\nTimeField\n\n\nA time representation.\n\n\nCorresponds to \ndjango.db.models.fields.TimeField\n\n\nSignature:\n \nTimeField(format=api_settings.TIME_FORMAT, input_formats=None)\n\n\n\n\nformat\n - A string representing the output format. If not specified, this defaults to the same value as the \nTIME_FORMAT\n settings key, which will be \n'iso-8601'\n unless set. Setting to a format string indicates that \nto_representation\n return values should be coerced to string output. Format strings are described below. Setting this value to \nNone\n indicates that Python \ntime\n objects should be returned by \nto_representation\n. In this case the time encoding will be determined by the renderer.\n\n\ninput_formats\n - A list of strings representing the input formats which may be used to parse the date. If not specified, the \nTIME_INPUT_FORMATS\n setting will be used, which defaults to \n['iso-8601']\n.\n\n\n\n\nTimeField\n format strings\n\n\nFormat strings may either be \nPython strftime formats\n which explicitly specify the format, or the special string \n'iso-8601'\n, which indicates that \nISO 8601\n style times should be used. (eg \n'12:34:56.000000'\n)\n\n\nDurationField\n\n\nA Duration representation.\nCorresponds to \ndjango.db.models.fields.DurationField\n\n\nThe \nvalidated_data\n for these fields will contain a \ndatetime.timedelta\n instance.\nThe representation is a string following this format \n'[DD] [HH:[MM:]]ss[.uuuuuu]'\n.\n\n\nNote:\n This field is only available with Django versions \n= 1.8.\n\n\nSignature:\n \nDurationField()\n\n\n\n\nChoice selection fields\n\n\nChoiceField\n\n\nA field that can accept a value out of a limited set of choices.\n\n\nUsed by \nModelSerializer\n to automatically generate fields if the corresponding model field includes a \nchoices=\u2026\n argument.\n\n\nSignature:\n \nChoiceField(choices)\n\n\n\n\nchoices\n - A list of valid values, or a list of \n(key, display_name)\n tuples.\n\n\nallow_blank\n - If set to \nTrue\n then the empty string should be considered a valid value. If set to \nFalse\n then the empty string is considered invalid and will raise a validation error. Defaults to \nFalse\n.\n\n\nhtml_cutoff\n - If set this will be the maximum number of choices that will be displayed by a HTML select drop down. Can be used to ensure that automatically generated ChoiceFields with very large possible selections do not prevent a template from rendering. Defaults to \nNone\n.\n\n\nhtml_cutoff_text\n - If set this will display a textual indicator if the maximum number of items have been cutoff in an HTML select drop down. Defaults to \n\"More than {count} items\u2026\"\n\n\n\n\nBoth the \nallow_blank\n and \nallow_null\n are valid options on \nChoiceField\n, although it is highly recommended that you only use one and not both. \nallow_blank\n should be preferred for textual choices, and \nallow_null\n should be preferred for numeric or other non-textual choices.\n\n\nMultipleChoiceField\n\n\nA field that can accept a set of zero, one or many values, chosen from a limited set of choices. Takes a single mandatory argument. \nto_internal_value\n returns a \nset\n containing the selected values.\n\n\nSignature:\n \nMultipleChoiceField(choices)\n\n\n\n\nchoices\n - A list of valid values, or a list of \n(key, display_name)\n tuples.\n\n\nallow_blank\n - If set to \nTrue\n then the empty string should be considered a valid value. If set to \nFalse\n then the empty string is considered invalid and will raise a validation error. Defaults to \nFalse\n.\n\n\nhtml_cutoff\n - If set this will be the maximum number of choices that will be displayed by a HTML select drop down. Can be used to ensure that automatically generated ChoiceFields with very large possible selections do not prevent a template from rendering. Defaults to \nNone\n.\n\n\nhtml_cutoff_text\n - If set this will display a textual indicator if the maximum number of items have been cutoff in an HTML select drop down. Defaults to \n\"More than {count} items\u2026\"\n\n\n\n\nAs with \nChoiceField\n, both the \nallow_blank\n and \nallow_null\n options are valid, although it is highly recommended that you only use one and not both. \nallow_blank\n should be preferred for textual choices, and \nallow_null\n should be preferred for numeric or other non-textual choices.\n\n\n\n\nFile upload fields\n\n\nParsers and file uploads.\n\n\nThe \nFileField\n and \nImageField\n classes are only suitable for use with \nMultiPartParser\n or \nFileUploadParser\n. Most parsers, such as e.g. JSON don't support file uploads.\nDjango's regular \nFILE_UPLOAD_HANDLERS\n are used for handling uploaded files.\n\n\nFileField\n\n\nA file representation. Performs Django's standard FileField validation.\n\n\nCorresponds to \ndjango.forms.fields.FileField\n.\n\n\nSignature:\n \nFileField(max_length=None, allow_empty_file=False, use_url=UPLOADED_FILES_USE_URL)\n\n\n\n\nmax_length\n - Designates the maximum length for the file name.\n\n\nallow_empty_file\n - Designates if empty files are allowed.\n\n\nuse_url\n - If set to \nTrue\n then URL string values will be used for the output representation. If set to \nFalse\n then filename string values will be used for the output representation. Defaults to the value of the \nUPLOADED_FILES_USE_URL\n settings key, which is \nTrue\n unless set otherwise.\n\n\n\n\nImageField\n\n\nAn image representation. Validates the uploaded file content as matching a known image format.\n\n\nCorresponds to \ndjango.forms.fields.ImageField\n.\n\n\nSignature:\n \nImageField(max_length=None, allow_empty_file=False, use_url=UPLOADED_FILES_USE_URL)\n\n\n\n\nmax_length\n - Designates the maximum length for the file name.\n\n\nallow_empty_file\n - Designates if empty files are allowed.\n\n\nuse_url\n - If set to \nTrue\n then URL string values will be used for the output representation. If set to \nFalse\n then filename string values will be used for the output representation. Defaults to the value of the \nUPLOADED_FILES_USE_URL\n settings key, which is \nTrue\n unless set otherwise.\n\n\n\n\nRequires either the \nPillow\n package or \nPIL\n package. The \nPillow\n package is recommended, as \nPIL\n is no longer actively maintained.\n\n\n\n\nComposite fields\n\n\nListField\n\n\nA field class that validates a list of objects.\n\n\nSignature\n: \nListField(child, min_length=None, max_length=None)\n\n\n\n\nchild\n - A field instance that should be used for validating the objects in the list. If this argument is not provided then objects in the list will not be validated.\n\n\nmin_length\n - Validates that the list contains no fewer than this number of elements.\n\n\nmax_length\n - Validates that the list contains no more than this number of elements.\n\n\n\n\nFor example, to validate a list of integers you might use something like the following:\n\n\nscores = serializers.ListField(\n child=serializers.IntegerField(min_value=0, max_value=100)\n)\n\n\n\nThe \nListField\n class also supports a declarative style that allows you to write reusable list field classes.\n\n\nclass StringListField(serializers.ListField):\n child = serializers.CharField()\n\n\n\nWe can now reuse our custom \nStringListField\n class throughout our application, without having to provide a \nchild\n argument to it.\n\n\nDictField\n\n\nA field class that validates a dictionary of objects. The keys in \nDictField\n are always assumed to be string values.\n\n\nSignature\n: \nDictField(child)\n\n\n\n\nchild\n - A field instance that should be used for validating the values in the dictionary. If this argument is not provided then values in the mapping will not be validated.\n\n\n\n\nFor example, to create a field that validates a mapping of strings to strings, you would write something like this:\n\n\ndocument = DictField(child=CharField())\n\n\n\nYou can also use the declarative style, as with \nListField\n. For example:\n\n\nclass DocumentField(DictField):\n child = CharField()\n\n\n\nJSONField\n\n\nA field class that validates that the incoming data structure consists of valid JSON primitives. In its alternate binary mode, it will represent and validate JSON-encoded binary strings.\n\n\nSignature\n: \nJSONField(binary)\n\n\n\n\nbinary\n - If set to \nTrue\n then the field will output and validate a JSON encoded string, rather than a primitive data structure. Defaults to \nFalse\n.\n\n\n\n\n\n\nMiscellaneous fields\n\n\nReadOnlyField\n\n\nA field class that simply returns the value of the field without modification.\n\n\nThis field is used by default with \nModelSerializer\n when including field names that relate to an attribute rather than a model field.\n\n\nSignature\n: \nReadOnlyField()\n\n\nFor example, if \nhas_expired\n was a property on the \nAccount\n model, then the following serializer would automatically generate it as a \nReadOnlyField\n:\n\n\nclass AccountSerializer(serializers.ModelSerializer):\n class Meta:\n model = Account\n fields = ('id', 'account_name', 'has_expired')\n\n\n\nHiddenField\n\n\nA field class that does not take a value based on user input, but instead takes its value from a default value or callable.\n\n\nSignature\n: \nHiddenField()\n\n\nFor example, to include a field that always provides the current time as part of the serializer validated data, you would use the following:\n\n\nmodified = serializers.HiddenField(default=timezone.now)\n\n\n\nThe \nHiddenField\n class is usually only needed if you have some validation that needs to run based on some pre-provided field values, but you do not want to expose all of those fields to the end user.\n\n\nFor further examples on \nHiddenField\n see the \nvalidators\n documentation.\n\n\nModelField\n\n\nA generic field that can be tied to any arbitrary model field. The \nModelField\n class delegates the task of serialization/deserialization to its associated model field. This field can be used to create serializer fields for custom model fields, without having to create a new custom serializer field.\n\n\nThis field is used by \nModelSerializer\n to correspond to custom model field classes.\n\n\nSignature:\n \nModelField(model_field=\nDjango ModelField instance\n)\n\n\nThe \nModelField\n class is generally intended for internal use, but can be used by your API if needed. In order to properly instantiate a \nModelField\n, it must be passed a field that is attached to an instantiated model. For example: \nModelField(model_field=MyModel()._meta.get_field('custom_field'))\n\n\nSerializerMethodField\n\n\nThis is a read-only field. It gets its value by calling a method on the serializer class it is attached to. It can be used to add any sort of data to the serialized representation of your object.\n\n\nSignature\n: \nSerializerMethodField(method_name=None)\n\n\n\n\nmethod_name\n - The name of the method on the serializer to be called. If not included this defaults to \nget_\nfield_name\n.\n\n\n\n\nThe serializer method referred to by the \nmethod_name\n argument should accept a single argument (in addition to \nself\n), which is the object being serialized. It should return whatever you want to be included in the serialized representation of the object. For example:\n\n\nfrom django.contrib.auth.models import User\nfrom django.utils.timezone import now\nfrom rest_framework import serializers\n\nclass UserSerializer(serializers.ModelSerializer):\n days_since_joined = serializers.SerializerMethodField()\n\n class Meta:\n model = User\n\n def get_days_since_joined(self, obj):\n return (now() - obj.date_joined).days\n\n\n\n\n\nCustom fields\n\n\nIf you want to create a custom field, you'll need to subclass \nField\n and then override either one or both of the \n.to_representation()\n and \n.to_internal_value()\n methods. These two methods are used to convert between the initial datatype, and a primitive, serializable datatype. Primitive datatypes will typically be any of a number, string, boolean, \ndate\n/\ntime\n/\ndatetime\n or \nNone\n. They may also be any list or dictionary like object that only contains other primitive objects. Other types might be supported, depending on the renderer that you are using.\n\n\nThe \n.to_representation()\n method is called to convert the initial datatype into a primitive, serializable datatype.\n\n\nThe \nto_internal_value()\n method is called to restore a primitive datatype into its internal python representation. This method should raise a \nserializers.ValidationError\n if the data is invalid.\n\n\nNote that the \nWritableField\n class that was present in version 2.x no longer exists. You should subclass \nField\n and override \nto_internal_value()\n if the field supports data input.\n\n\nExamples\n\n\nLet's look at an example of serializing a class that represents an RGB color value:\n\n\nclass Color(object):\n \"\"\"\n A color represented in the RGB colorspace.\n \"\"\"\n def __init__(self, red, green, blue):\n assert(red \n= 0 and green \n= 0 and blue \n= 0)\n assert(red \n 256 and green \n 256 and blue \n 256)\n self.red, self.green, self.blue = red, green, blue\n\nclass ColorField(serializers.Field):\n \"\"\"\n Color objects are serialized into 'rgb(#, #, #)' notation.\n \"\"\"\n def to_representation(self, obj):\n return \"rgb(%d, %d, %d)\" % (obj.red, obj.green, obj.blue)\n\n def to_internal_value(self, data):\n data = data.strip('rgb(').rstrip(')')\n red, green, blue = [int(col) for col in data.split(',')]\n return Color(red, green, blue)\n\n\n\nBy default field values are treated as mapping to an attribute on the object. If you need to customize how the field value is accessed and set you need to override \n.get_attribute()\n and/or \n.get_value()\n.\n\n\nAs an example, let's create a field that can be used to represent the class name of the object being serialized:\n\n\nclass ClassNameField(serializers.Field):\n def get_attribute(self, obj):\n # We pass the object instance onto `to_representation`,\n # not just the field attribute.\n return obj\n\n def to_representation(self, obj):\n \"\"\"\n Serialize the object's class name.\n \"\"\"\n return obj.__class__.__name__\n\n\n\nRaising validation errors\n\n\nOur \nColorField\n class above currently does not perform any data validation.\nTo indicate invalid data, we should raise a \nserializers.ValidationError\n, like so:\n\n\ndef to_internal_value(self, data):\n if not isinstance(data, six.text_type):\n msg = 'Incorrect type. Expected a string, but got %s'\n raise ValidationError(msg % type(data).__name__)\n\n if not re.match(r'^rgb\\([0-9]+,[0-9]+,[0-9]+\\)$', data):\n raise ValidationError('Incorrect format. Expected `rgb(#,#,#)`.')\n\n data = data.strip('rgb(').rstrip(')')\n red, green, blue = [int(col) for col in data.split(',')]\n\n if any([col \n 255 or col \n 0 for col in (red, green, blue)]):\n raise ValidationError('Value out of range. Must be between 0 and 255.')\n\n return Color(red, green, blue)\n\n\n\nThe \n.fail()\n method is a shortcut for raising \nValidationError\n that takes a message string from the \nerror_messages\n dictionary. For example:\n\n\ndefault_error_messages = {\n 'incorrect_type': 'Incorrect type. Expected a string, but got {input_type}',\n 'incorrect_format': 'Incorrect format. Expected `rgb(#,#,#)`.',\n 'out_of_range': 'Value out of range. Must be between 0 and 255.'\n}\n\ndef to_internal_value(self, data):\n if not isinstance(data, six.text_type):\n self.fail('incorrect_type', input_type=type(data).__name__)\n\n if not re.match(r'^rgb\\([0-9]+,[0-9]+,[0-9]+\\)$', data):\n self.fail('incorrect_format')\n\n data = data.strip('rgb(').rstrip(')')\n red, green, blue = [int(col) for col in data.split(',')]\n\n if any([col \n 255 or col \n 0 for col in (red, green, blue)]):\n self.fail('out_of_range')\n\n return Color(red, green, blue)\n\n\n\nThis style keeps you error messages more cleanly separated from your code, and should be preferred.\n\n\nThird party packages\n\n\nThe following third party packages are also available.\n\n\nDRF Compound Fields\n\n\nThe \ndrf-compound-fields\n package provides \"compound\" serializer fields, such as lists of simple values, which can be described by other fields rather than serializers with the \nmany=True\n option. Also provided are fields for typed dictionaries and values that can be either a specific type or a list of items of that type.\n\n\nDRF Extra Fields\n\n\nThe \ndrf-extra-fields\n package provides extra serializer fields for REST framework, including \nBase64ImageField\n and \nPointField\n classes.\n\n\ndjangrestframework-recursive\n\n\nthe \ndjangorestframework-recursive\n package provides a \nRecursiveField\n for serializing and deserializing recursive structures\n\n\ndjango-rest-framework-gis\n\n\nThe \ndjango-rest-framework-gis\n package provides geographic addons for django rest framework like a \nGeometryField\n field and a GeoJSON serializer.\n\n\ndjango-rest-framework-hstore\n\n\nThe \ndjango-rest-framework-hstore\n package provides an \nHStoreField\n to support \ndjango-hstore\n \nDictionaryField\n model field.", "title": "Serializer fields" }, { @@ -1902,7 +1907,7 @@ }, { "location": "/api-guide/fields/#datetimefield-format-strings", - "text": "Format strings may either be Python strftime formats which explicitly specify the format, or the special string 'iso-8601' , which indicates that ISO 8601 style datetimes should be used. (eg '2013-01-29T12:34:56.000000Z' ) When a value of None is used for the format datetime objects will be returned by to_representation and the final output representation will determined by the renderer class. In the case of JSON this means the default datetime representation uses the ECMA 262 date time string specification . This is a subset of ISO 8601 which uses millisecond precision, and includes the 'Z' suffix for the UTC timezone, for example: 2013-01-29T12:34:56.123Z .", + "text": "Format strings may either be Python strftime formats which explicitly specify the format, or the special string 'iso-8601' , which indicates that ISO 8601 style datetimes should be used. (eg '2013-01-29T12:34:56.000000Z' ) When a value of None is used for the format datetime objects will be returned by to_representation and the final output representation will determined by the renderer class.", "title": "DateTimeField format strings." }, { @@ -4301,168 +4306,188 @@ "title": "What REST framework doesn't provide." }, { - "location": "/topics/third-party-resources/", - "text": "Third Party Resources\n\n\n\n\nSoftware ecosystems [\u2026] establish a community that further accelerates the sharing of knowledge, content, issues, expertise and skills.\n\n\n \nJan Bosch\n.\n\n\n\n\nAbout Third Party Packages\n\n\nThird Party Packages allow developers to share code that extends the functionality of Django REST framework, in order to support additional use-cases.\n\n\nWe \nsupport\n, \nencourage\n and \nstrongly favor\n the creation of Third Party Packages to encapsulate new behavior rather than adding additional functionality directly to Django REST Framework.\n\n\nWe aim to make creating third party packages as easy as possible, whilst keeping a \nsimple\n and \nwell maintained\n core API. By promoting third party packages we ensure that the responsibility for a package remains with its author. If a package proves suitably popular it can always be considered for inclusion into the core REST framework.\n\n\nIf you have an idea for a new feature please consider how it may be packaged as a Third Party Package. We're always happy to discuss ideas on the \nMailing List\n.\n\n\nHow to create a Third Party Package\n\n\nCreating your package\n\n\nYou can use \nthis cookiecutter template\n for creating reusable Django REST Framework packages quickly. Cookiecutter creates projects from project templates. While optional, this cookiecutter template includes best practices from Django REST framework and other packages, as well as a Travis CI configuration, Tox configuration, and a sane setup.py for easy PyPI registration/distribution.\n\n\nNote: Let us know if you have an alternate cookiecuter package so we can also link to it.\n\n\nRunning the initial cookiecutter command\n\n\nTo run the initial cookiecutter command, you'll first need to install the Python \ncookiecutter\n package.\n\n\n$ pip install cookiecutter\n\n\n\nOnce \ncookiecutter\n is installed just run the following to create a new project.\n\n\n$ cookiecutter gh:jpadilla/cookiecutter-django-rest-framework\n\n\n\nYou'll be prompted for some questions, answer them, then it'll create your Python package in the current working directory based on those values.\n\n\nfull_name (default is \"Your full name here\")? Johnny Appleseed\nemail (default is \"you@example.com\")? jappleseed@example.com\ngithub_username (default is \"yourname\")? jappleseed\npypi_project_name (default is \"dj-package\")? djangorestframework-custom-auth\nrepo_name (default is \"dj-package\")? django-rest-framework-custom-auth\napp_name (default is \"djpackage\")? custom_auth\nproject_short_description (default is \"Your project description goes here\")?\nyear (default is \"2014\")?\nversion (default is \"0.1.0\")?\n\n\n\nGetting it onto GitHub\n\n\nTo put your project up on GitHub, you'll need a repository for it to live in. You can create a new repository \nhere\n. If you need help, check out the \nCreate A Repo\n article on GitHub.\n\n\nAdding to Travis CI\n\n\nWe recommend using \nTravis CI\n, a hosted continuous integration service which integrates well with GitHub and is free for public repositories.\n\n\nTo get started with Travis CI, \nsign in\n with your GitHub account. Once you're signed in, go to your \nprofile page\n and enable the service hook for the repository you want.\n\n\nIf you use the cookiecutter template, your project will already contain a \n.travis.yml\n file which Travis CI will use to build your project and run tests. By default, builds are triggered everytime you push to your repository or create Pull Request.\n\n\nUploading to PyPI\n\n\nOnce you've got at least a prototype working and tests running, you should publish it on PyPI to allow others to install it via \npip\n.\n\n\nYou must \nregister\n an account before publishing to PyPI.\n\n\nTo register your package on PyPI run the following command.\n\n\n$ python setup.py register\n\n\n\nIf this is the first time publishing to PyPI, you'll be prompted to login.\n\n\nNote: Before publishing you'll need to make sure you have the latest pip that supports \nwheel\n as well as install the \nwheel\n package.\n\n\n$ pip install --upgrade pip\n$ pip install wheel\n\n\n\nAfter this, every time you want to release a new version on PyPI just run the following command.\n\n\n$ python setup.py publish\nYou probably want to also tag the version now:\n git tag -a {0} -m 'version 0.1.0'\n git push --tags\n\n\n\nAfter releasing a new version to PyPI, it's always a good idea to tag the version and make available as a GitHub Release.\n\n\nWe recommend to follow \nSemantic Versioning\n for your package's versions.\n\n\nDevelopment\n\n\nVersion requirements\n\n\nThe cookiecutter template assumes a set of supported versions will be provided for Python and Django. Make sure you correctly update your requirements, docs, \ntox.ini\n, \n.travis.yml\n, and \nsetup.py\n to match the set of versions you wish to support.\n\n\nTests\n\n\nThe cookiecutter template includes a \nruntests.py\n which uses the \npytest\n package as a test runner.\n\n\nBefore running, you'll need to install a couple test requirements.\n\n\n$ pip install -r requirements.txt\n\n\n\nOnce requirements installed, you can run \nruntests.py\n.\n\n\n$ ./runtests.py\n\n\n\nRun using a more concise output style.\n\n\n$ ./runtests.py -q\n\n\n\nRun the tests using a more concise output style, no coverage, no flake8.\n\n\n$ ./runtests.py --fast\n\n\n\nDon't run the flake8 code linting.\n\n\n$ ./runtests.py --nolint\n\n\n\nOnly run the flake8 code linting, don't run the tests.\n\n\n$ ./runtests.py --lintonly\n\n\n\nRun the tests for a given test case.\n\n\n$ ./runtests.py MyTestCase\n\n\n\nRun the tests for a given test method.\n\n\n$ ./runtests.py MyTestCase.test_this_method\n\n\n\nShorter form to run the tests for a given test method.\n\n\n$ ./runtests.py test_this_method\n\n\n\nTo run your tests against multiple versions of Python as different versions of requirements such as Django we recommend using \ntox\n. \nTox\n is a generic virtualenv management and test command line tool.\n\n\nFirst, install \ntox\n globally.\n\n\n$ pip install tox\n\n\n\nTo run \ntox\n, just simply run:\n\n\n$ tox\n\n\n\nTo run a particular \ntox\n environment:\n\n\n$ tox -e envlist\n\n\n\nenvlist\n is a comma-separated value to that specifies the environments to run tests against. To view a list of all possible test environments, run:\n\n\n$ tox -l\n\n\n\nVersion compatibility\n\n\nSometimes, in order to ensure your code works on various different versions of Django, Python or third party libraries, you'll need to run slightly different code depending on the environment. Any code that branches in this way should be isolated into a \ncompat.py\n module, and should provide a single common interface that the rest of the codebase can use.\n\n\nCheck out Django REST framework's \ncompat.py\n for an example.\n\n\nOnce your package is available\n\n\nOnce your package is decently documented and available on PyPI, you might want share it with others that might find it useful.\n\n\nAdding to the Django REST framework grid\n\n\nWe suggest adding your package to the \nREST Framework\n grid on Django Packages.\n\n\nAdding to the Django REST framework docs\n\n\nCreate a \nPull Request\n or \nIssue\n on GitHub, and we'll add a link to it from the main REST framework documentation. You can add your package under \nThird party packages\n of the API Guide section that best applies, like \nAuthentication\n or \nPermissions\n. You can also link your package under the \nThird Party Resources\n section.\n\n\nAnnounce on the discussion group.\n\n\nYou can also let others know about your package through the \ndiscussion group\n.\n\n\nExisting Third Party Packages\n\n\nDjango REST Framework has a growing community of developers, packages, and resources.\n\n\nCheck out a grid detailing all the packages and ecosystem around Django REST Framework at \nDjango Packages\n.\n\n\nTo submit new content, \nopen an issue\n or \ncreate a pull request\n.\n\n\nAuthentication\n\n\n\n\ndjangorestframework-digestauth\n - Provides Digest Access Authentication support.\n\n\ndjango-oauth-toolkit\n - Provides OAuth 2.0 support.\n\n\ndoac\n - Provides OAuth 2.0 support.\n\n\ndjangorestframework-jwt\n - Provides JSON Web Token Authentication support.\n\n\nhawkrest\n - Provides Hawk HTTP Authorization.\n\n\ndjangorestframework-httpsignature\n - Provides an easy to use HTTP Signature Authentication mechanism.\n\n\ndjoser\n - Provides a set of views to handle basic actions such as registration, login, logout, password reset and account activation.\n\n\ndjango-rest-auth\n - Provides a set of REST API endpoints for registration, authentication (including social media authentication), password reset, retrieve and update user details, etc.\n\n\ndrf-oidc-auth\n - Implements OpenID Connect token authentication for DRF.\n\n\n\n\nPermissions\n\n\n\n\ndrf-any-permissions\n - Provides alternative permission handling.\n\n\ndjangorestframework-composed-permissions\n - Provides a simple way to define complex permissions.\n\n\nrest_condition\n - Another extension for building complex permissions in a simple and convenient way.\n\n\ndry-rest-permissions\n - Provides a simple way to define permissions for individual api actions.\n\n\n\n\nSerializers\n\n\n\n\ndjango-rest-framework-mongoengine\n - Serializer class that supports using MongoDB as the storage layer for Django REST framework.\n\n\ndjangorestframework-gis\n - Geographic add-ons\n\n\ndjangorestframework-hstore\n - Serializer class to support django-hstore DictionaryField model field and its schema-mode feature.\n\n\ndjangorestframework-jsonapi\n - Provides a parser, renderer, serializers, and other tools to help build an API that is compliant with the jsonapi.org spec.\n\n\nhtml-json-forms\n - Provides an algorithm and serializer to process HTML JSON Form submissions per the (inactive) spec.\n\n\ndjango-rest-framework-serializer-extensions\n -\n Enables black/whitelisting fields, and conditionally expanding child serializers on a per-view/request basis.\n\n\ndjangorestframework-queryfields\n - Serializer mixin allowing clients to control which fields will be sent in the API response.\n\n\n\n\nSerializer fields\n\n\n\n\ndrf-compound-fields\n - Provides \"compound\" serializer fields, such as lists of simple values.\n\n\ndjango-extra-fields\n - Provides extra serializer fields.\n\n\ndjango-versatileimagefield\n - Provides a drop-in replacement for Django's stock \nImageField\n that makes it easy to serve images in multiple sizes/renditions from a single field. For DRF-specific implementation docs, \nclick here\n.\n\n\n\n\nViews\n\n\n\n\ndjangorestframework-bulk\n - Implements generic view mixins as well as some common concrete generic views to allow to apply bulk operations via API requests.\n\n\ndjango-rest-multiple-models\n - Provides a generic view (and mixin) for sending multiple serialized models and/or querysets via a single API request.\n\n\n\n\nRouters\n\n\n\n\ndrf-nested-routers\n - Provides routers and relationship fields for working with nested resources.\n\n\nwq.db.rest\n - Provides an admin-style model registration API with reasonable default URLs and viewsets.\n\n\n\n\nParsers\n\n\n\n\ndjangorestframework-msgpack\n - Provides MessagePack renderer and parser support.\n\n\ndjangorestframework-jsonapi\n - Provides a parser, renderer, serializers, and other tools to help build an API that is compliant with the jsonapi.org spec.\n\n\ndjangorestframework-camel-case\n - Provides camel case JSON renderers and parsers.\n\n\n\n\nRenderers\n\n\n\n\ndjangorestframework-csv\n - Provides CSV renderer support.\n\n\ndjangorestframework-jsonapi\n - Provides a parser, renderer, serializers, and other tools to help build an API that is compliant with the jsonapi.org spec.\n\n\ndrf_ujson\n - Implements JSON rendering using the UJSON package.\n\n\nrest-pandas\n - Pandas DataFrame-powered renderers including Excel, CSV, and SVG formats.\n\n\n\n\nFiltering\n\n\n\n\ndjangorestframework-chain\n - Allows arbitrary chaining of both relations and lookup filters.\n\n\ndjango-url-filter\n - Allows a safe way to filter data via human-friendly URLs. It is a generic library which is not tied to DRF but it provides easy integration with DRF.\n\n\ndrf-url-filter\n is a simple Django app to apply filters on drf \nModelViewSet\n's \nQueryset\n in a clean, simple and configurable way. It also supports validations on incoming query params and their values.\n\n\n\n\nMisc\n\n\n\n\ncookiecutter-django-rest\n - A cookiecutter template that takes care of the setup and configuration so you can focus on making your REST apis awesome.\n\n\ndjangorestrelationalhyperlink\n - A hyperlinked serialiser that can can be used to alter relationships via hyperlinks, but otherwise like a hyperlink model serializer.\n\n\ndjango-rest-swagger\n - An API documentation generator for Swagger UI.\n\n\ndjango-rest-framework-proxy\n - Proxy to redirect incoming request to another API server.\n\n\ngaiarestframework\n - Utils for django-rest-framework\n\n\ndrf-extensions\n - A collection of custom extensions\n\n\nember-django-adapter\n - An adapter for working with Ember.js\n\n\ndjango-versatileimagefield\n - Provides a drop-in replacement for Django's stock \nImageField\n that makes it easy to serve images in multiple sizes/renditions from a single field. For DRF-specific implementation docs, \nclick here\n.\n\n\ndrf-tracking\n - Utilities to track requests to DRF API views.\n\n\ndrf_tweaks\n - Serializers with one-step validation (and more), pagination without counts and other tweaks.\n\n\ndjango-rest-framework-braces\n - Collection of utilities for working with Django Rest Framework. The most notable ones are \nFormSerializer\n and \nSerializerForm\n, which are adapters between DRF serializers and Django forms.\n\n\ndrf-haystack\n - Haystack search for Django Rest Framework\n\n\ndjango-rest-framework-version-transforms\n - Enables the use of delta transformations for versioning of DRF resource representations.\n\n\ndjango-rest-messaging\n, \ndjango-rest-messaging-centrifugo\n and \ndjango-rest-messaging-js\n - A real-time pluggable messaging service using DRM.\n\n\n\n\nOther Resources\n\n\nTutorials\n\n\n\n\nBeginner's Guide to the Django Rest Framework\n\n\nGetting Started with Django Rest Framework and AngularJS\n\n\nEnd to end web app with Django-Rest-Framework \n AngularJS\n\n\nStart Your API - django-rest-framework part 1\n\n\nPermissions \n Authentication - django-rest-framework part 2\n\n\nViewSets and Routers - django-rest-framework part 3\n\n\nDjango Rest Framework User Endpoint\n\n\nCheck credentials using Django Rest Framework\n\n\nDjango REST Framework course\n\n\n\n\nVideos\n\n\n\n\nEmber and Django Part 1 (Video)\n\n\nDjango Rest Framework Part 1 (Video)\n\n\n\n\nArticles\n\n\n\n\nWeb API performance: profiling Django REST framework\n\n\nAPI Development with Django and Django REST Framework\n\n\nBlog posts about Django REST framework\n\n\n\n\nDocumentations\n\n\n\n\nClassy Django REST Framework", - "title": "Third Party Resources" + "location": "/topics/third-party-packages/", + "text": "Third Party Packages\n\n\n\n\nSoftware ecosystems [\u2026] establish a community that further accelerates the sharing of knowledge, content, issues, expertise and skills.\n\n\n \nJan Bosch\n.\n\n\n\n\nAbout Third Party Packages\n\n\nThird Party Packages allow developers to share code that extends the functionality of Django REST framework, in order to support additional use-cases.\n\n\nWe \nsupport\n, \nencourage\n and \nstrongly favor\n the creation of Third Party Packages to encapsulate new behavior rather than adding additional functionality directly to Django REST Framework.\n\n\nWe aim to make creating third party packages as easy as possible, whilst keeping a \nsimple\n and \nwell maintained\n core API. By promoting third party packages we ensure that the responsibility for a package remains with its author. If a package proves suitably popular it can always be considered for inclusion into the core REST framework.\n\n\nIf you have an idea for a new feature please consider how it may be packaged as a Third Party Package. We're always happy to discuss ideas on the \nMailing List\n.\n\n\nHow to create a Third Party Package\n\n\nCreating your package\n\n\nYou can use \nthis cookiecutter template\n for creating reusable Django REST Framework packages quickly. Cookiecutter creates projects from project templates. While optional, this cookiecutter template includes best practices from Django REST framework and other packages, as well as a Travis CI configuration, Tox configuration, and a sane setup.py for easy PyPI registration/distribution.\n\n\nNote: Let us know if you have an alternate cookiecuter package so we can also link to it.\n\n\nRunning the initial cookiecutter command\n\n\nTo run the initial cookiecutter command, you'll first need to install the Python \ncookiecutter\n package.\n\n\n$ pip install cookiecutter\n\n\n\nOnce \ncookiecutter\n is installed just run the following to create a new project.\n\n\n$ cookiecutter gh:jpadilla/cookiecutter-django-rest-framework\n\n\n\nYou'll be prompted for some questions, answer them, then it'll create your Python package in the current working directory based on those values.\n\n\nfull_name (default is \"Your full name here\")? Johnny Appleseed\nemail (default is \"you@example.com\")? jappleseed@example.com\ngithub_username (default is \"yourname\")? jappleseed\npypi_project_name (default is \"dj-package\")? djangorestframework-custom-auth\nrepo_name (default is \"dj-package\")? django-rest-framework-custom-auth\napp_name (default is \"djpackage\")? custom_auth\nproject_short_description (default is \"Your project description goes here\")?\nyear (default is \"2014\")?\nversion (default is \"0.1.0\")?\n\n\n\nGetting it onto GitHub\n\n\nTo put your project up on GitHub, you'll need a repository for it to live in. You can create a new repository \nhere\n. If you need help, check out the \nCreate A Repo\n article on GitHub.\n\n\nAdding to Travis CI\n\n\nWe recommend using \nTravis CI\n, a hosted continuous integration service which integrates well with GitHub and is free for public repositories.\n\n\nTo get started with Travis CI, \nsign in\n with your GitHub account. Once you're signed in, go to your \nprofile page\n and enable the service hook for the repository you want.\n\n\nIf you use the cookiecutter template, your project will already contain a \n.travis.yml\n file which Travis CI will use to build your project and run tests. By default, builds are triggered everytime you push to your repository or create Pull Request.\n\n\nUploading to PyPI\n\n\nOnce you've got at least a prototype working and tests running, you should publish it on PyPI to allow others to install it via \npip\n.\n\n\nYou must \nregister\n an account before publishing to PyPI.\n\n\nTo register your package on PyPI run the following command.\n\n\n$ python setup.py register\n\n\n\nIf this is the first time publishing to PyPI, you'll be prompted to login.\n\n\nNote: Before publishing you'll need to make sure you have the latest pip that supports \nwheel\n as well as install the \nwheel\n package.\n\n\n$ pip install --upgrade pip\n$ pip install wheel\n\n\n\nAfter this, every time you want to release a new version on PyPI just run the following command.\n\n\n$ python setup.py publish\nYou probably want to also tag the version now:\n git tag -a {0} -m 'version 0.1.0'\n git push --tags\n\n\n\nAfter releasing a new version to PyPI, it's always a good idea to tag the version and make available as a GitHub Release.\n\n\nWe recommend to follow \nSemantic Versioning\n for your package's versions.\n\n\nDevelopment\n\n\nVersion requirements\n\n\nThe cookiecutter template assumes a set of supported versions will be provided for Python and Django. Make sure you correctly update your requirements, docs, \ntox.ini\n, \n.travis.yml\n, and \nsetup.py\n to match the set of versions you wish to support.\n\n\nTests\n\n\nThe cookiecutter template includes a \nruntests.py\n which uses the \npytest\n package as a test runner.\n\n\nBefore running, you'll need to install a couple test requirements.\n\n\n$ pip install -r requirements.txt\n\n\n\nOnce requirements installed, you can run \nruntests.py\n.\n\n\n$ ./runtests.py\n\n\n\nRun using a more concise output style.\n\n\n$ ./runtests.py -q\n\n\n\nRun the tests using a more concise output style, no coverage, no flake8.\n\n\n$ ./runtests.py --fast\n\n\n\nDon't run the flake8 code linting.\n\n\n$ ./runtests.py --nolint\n\n\n\nOnly run the flake8 code linting, don't run the tests.\n\n\n$ ./runtests.py --lintonly\n\n\n\nRun the tests for a given test case.\n\n\n$ ./runtests.py MyTestCase\n\n\n\nRun the tests for a given test method.\n\n\n$ ./runtests.py MyTestCase.test_this_method\n\n\n\nShorter form to run the tests for a given test method.\n\n\n$ ./runtests.py test_this_method\n\n\n\nTo run your tests against multiple versions of Python as different versions of requirements such as Django we recommend using \ntox\n. \nTox\n is a generic virtualenv management and test command line tool.\n\n\nFirst, install \ntox\n globally.\n\n\n$ pip install tox\n\n\n\nTo run \ntox\n, just simply run:\n\n\n$ tox\n\n\n\nTo run a particular \ntox\n environment:\n\n\n$ tox -e envlist\n\n\n\nenvlist\n is a comma-separated value to that specifies the environments to run tests against. To view a list of all possible test environments, run:\n\n\n$ tox -l\n\n\n\nVersion compatibility\n\n\nSometimes, in order to ensure your code works on various different versions of Django, Python or third party libraries, you'll need to run slightly different code depending on the environment. Any code that branches in this way should be isolated into a \ncompat.py\n module, and should provide a single common interface that the rest of the codebase can use.\n\n\nCheck out Django REST framework's \ncompat.py\n for an example.\n\n\nOnce your package is available\n\n\nOnce your package is decently documented and available on PyPI, you might want share it with others that might find it useful.\n\n\nAdding to the Django REST framework grid\n\n\nWe suggest adding your package to the \nREST Framework\n grid on Django Packages.\n\n\nAdding to the Django REST framework docs\n\n\nCreate a \nPull Request\n or \nIssue\n on GitHub, and we'll add a link to it from the main REST framework documentation. You can add your package under \nThird party packages\n of the API Guide section that best applies, like \nAuthentication\n or \nPermissions\n. You can also link your package under the \nThird Party Packages\n section.\n\n\nAnnounce on the discussion group.\n\n\nYou can also let others know about your package through the \ndiscussion group\n.\n\n\nExisting Third Party Packages\n\n\nDjango REST Framework has a growing community of developers, packages, and resources.\n\n\nCheck out a grid detailing all the packages and ecosystem around Django REST Framework at \nDjango Packages\n.\n\n\nTo submit new content, \nopen an issue\n or \ncreate a pull request\n.\n\n\nAuthentication\n\n\n\n\ndjangorestframework-digestauth\n - Provides Digest Access Authentication support.\n\n\ndjango-oauth-toolkit\n - Provides OAuth 2.0 support.\n\n\ndoac\n - Provides OAuth 2.0 support.\n\n\ndjangorestframework-jwt\n - Provides JSON Web Token Authentication support.\n\n\nhawkrest\n - Provides Hawk HTTP Authorization.\n\n\ndjangorestframework-httpsignature\n - Provides an easy to use HTTP Signature Authentication mechanism.\n\n\ndjoser\n - Provides a set of views to handle basic actions such as registration, login, logout, password reset and account activation.\n\n\ndjango-rest-auth\n - Provides a set of REST API endpoints for registration, authentication (including social media authentication), password reset, retrieve and update user details, etc.\n\n\ndrf-oidc-auth\n - Implements OpenID Connect token authentication for DRF.\n\n\n\n\nPermissions\n\n\n\n\ndrf-any-permissions\n - Provides alternative permission handling.\n\n\ndjangorestframework-composed-permissions\n - Provides a simple way to define complex permissions.\n\n\nrest_condition\n - Another extension for building complex permissions in a simple and convenient way.\n\n\ndry-rest-permissions\n - Provides a simple way to define permissions for individual api actions.\n\n\n\n\nSerializers\n\n\n\n\ndjango-rest-framework-mongoengine\n - Serializer class that supports using MongoDB as the storage layer for Django REST framework.\n\n\ndjangorestframework-gis\n - Geographic add-ons\n\n\ndjangorestframework-hstore\n - Serializer class to support django-hstore DictionaryField model field and its schema-mode feature.\n\n\ndjangorestframework-jsonapi\n - Provides a parser, renderer, serializers, and other tools to help build an API that is compliant with the jsonapi.org spec.\n\n\nhtml-json-forms\n - Provides an algorithm and serializer to process HTML JSON Form submissions per the (inactive) spec.\n\n\ndjango-rest-framework-serializer-extensions\n -\n Enables black/whitelisting fields, and conditionally expanding child serializers on a per-view/request basis.\n\n\ndjangorestframework-queryfields\n - Serializer mixin allowing clients to control which fields will be sent in the API response.\n\n\n\n\nSerializer fields\n\n\n\n\ndrf-compound-fields\n - Provides \"compound\" serializer fields, such as lists of simple values.\n\n\ndjango-extra-fields\n - Provides extra serializer fields.\n\n\ndjango-versatileimagefield\n - Provides a drop-in replacement for Django's stock \nImageField\n that makes it easy to serve images in multiple sizes/renditions from a single field. For DRF-specific implementation docs, \nclick here\n.\n\n\n\n\nViews\n\n\n\n\ndjangorestframework-bulk\n - Implements generic view mixins as well as some common concrete generic views to allow to apply bulk operations via API requests.\n\n\ndjango-rest-multiple-models\n - Provides a generic view (and mixin) for sending multiple serialized models and/or querysets via a single API request.\n\n\n\n\nRouters\n\n\n\n\ndrf-nested-routers\n - Provides routers and relationship fields for working with nested resources.\n\n\nwq.db.rest\n - Provides an admin-style model registration API with reasonable default URLs and viewsets.\n\n\n\n\nParsers\n\n\n\n\ndjangorestframework-msgpack\n - Provides MessagePack renderer and parser support.\n\n\ndjangorestframework-jsonapi\n - Provides a parser, renderer, serializers, and other tools to help build an API that is compliant with the jsonapi.org spec.\n\n\ndjangorestframework-camel-case\n - Provides camel case JSON renderers and parsers.\n\n\n\n\nRenderers\n\n\n\n\ndjangorestframework-csv\n - Provides CSV renderer support.\n\n\ndjangorestframework-jsonapi\n - Provides a parser, renderer, serializers, and other tools to help build an API that is compliant with the jsonapi.org spec.\n\n\ndrf_ujson\n - Implements JSON rendering using the UJSON package.\n\n\nrest-pandas\n - Pandas DataFrame-powered renderers including Excel, CSV, and SVG formats.\n\n\n\n\nFiltering\n\n\n\n\ndjangorestframework-chain\n - Allows arbitrary chaining of both relations and lookup filters.\n\n\ndjango-url-filter\n - Allows a safe way to filter data via human-friendly URLs. It is a generic library which is not tied to DRF but it provides easy integration with DRF.\n\n\ndrf-url-filter\n is a simple Django app to apply filters on drf \nModelViewSet\n's \nQueryset\n in a clean, simple and configurable way. It also supports validations on incoming query params and their values.\n\n\n\n\nMisc\n\n\n\n\ncookiecutter-django-rest\n - A cookiecutter template that takes care of the setup and configuration so you can focus on making your REST apis awesome.\n\n\ndjangorestrelationalhyperlink\n - A hyperlinked serialiser that can can be used to alter relationships via hyperlinks, but otherwise like a hyperlink model serializer.\n\n\ndjango-rest-swagger\n - An API documentation generator for Swagger UI.\n\n\ndjango-rest-framework-proxy\n - Proxy to redirect incoming request to another API server.\n\n\ngaiarestframework\n - Utils for django-rest-framework\n\n\ndrf-extensions\n - A collection of custom extensions\n\n\nember-django-adapter\n - An adapter for working with Ember.js\n\n\ndjango-versatileimagefield\n - Provides a drop-in replacement for Django's stock \nImageField\n that makes it easy to serve images in multiple sizes/renditions from a single field. For DRF-specific implementation docs, \nclick here\n.\n\n\ndrf-tracking\n - Utilities to track requests to DRF API views.\n\n\ndrf_tweaks\n - Serializers with one-step validation (and more), pagination without counts and other tweaks.\n\n\ndjango-rest-framework-braces\n - Collection of utilities for working with Django Rest Framework. The most notable ones are \nFormSerializer\n and \nSerializerForm\n, which are adapters between DRF serializers and Django forms.\n\n\ndrf-haystack\n - Haystack search for Django Rest Framework\n\n\ndjango-rest-framework-version-transforms\n - Enables the use of delta transformations for versioning of DRF resource representations.\n\n\ndjango-rest-messaging\n, \ndjango-rest-messaging-centrifugo\n and \ndjango-rest-messaging-js\n - A real-time pluggable messaging service using DRM.", + "title": "Third Party Packages" }, { - "location": "/topics/third-party-resources/#third-party-resources", + "location": "/topics/third-party-packages/#third-party-packages", "text": "Software ecosystems [\u2026] establish a community that further accelerates the sharing of knowledge, content, issues, expertise and skills. Jan Bosch .", - "title": "Third Party Resources" + "title": "Third Party Packages" }, { - "location": "/topics/third-party-resources/#about-third-party-packages", + "location": "/topics/third-party-packages/#about-third-party-packages", "text": "Third Party Packages allow developers to share code that extends the functionality of Django REST framework, in order to support additional use-cases. We support , encourage and strongly favor the creation of Third Party Packages to encapsulate new behavior rather than adding additional functionality directly to Django REST Framework. We aim to make creating third party packages as easy as possible, whilst keeping a simple and well maintained core API. By promoting third party packages we ensure that the responsibility for a package remains with its author. If a package proves suitably popular it can always be considered for inclusion into the core REST framework. If you have an idea for a new feature please consider how it may be packaged as a Third Party Package. We're always happy to discuss ideas on the Mailing List .", "title": "About Third Party Packages" }, { - "location": "/topics/third-party-resources/#how-to-create-a-third-party-package", + "location": "/topics/third-party-packages/#how-to-create-a-third-party-package", "text": "", "title": "How to create a Third Party Package" }, { - "location": "/topics/third-party-resources/#creating-your-package", + "location": "/topics/third-party-packages/#creating-your-package", "text": "You can use this cookiecutter template for creating reusable Django REST Framework packages quickly. Cookiecutter creates projects from project templates. While optional, this cookiecutter template includes best practices from Django REST framework and other packages, as well as a Travis CI configuration, Tox configuration, and a sane setup.py for easy PyPI registration/distribution. Note: Let us know if you have an alternate cookiecuter package so we can also link to it.", "title": "Creating your package" }, { - "location": "/topics/third-party-resources/#running-the-initial-cookiecutter-command", + "location": "/topics/third-party-packages/#running-the-initial-cookiecutter-command", "text": "To run the initial cookiecutter command, you'll first need to install the Python cookiecutter package. $ pip install cookiecutter Once cookiecutter is installed just run the following to create a new project. $ cookiecutter gh:jpadilla/cookiecutter-django-rest-framework You'll be prompted for some questions, answer them, then it'll create your Python package in the current working directory based on those values. full_name (default is \"Your full name here\")? Johnny Appleseed\nemail (default is \"you@example.com\")? jappleseed@example.com\ngithub_username (default is \"yourname\")? jappleseed\npypi_project_name (default is \"dj-package\")? djangorestframework-custom-auth\nrepo_name (default is \"dj-package\")? django-rest-framework-custom-auth\napp_name (default is \"djpackage\")? custom_auth\nproject_short_description (default is \"Your project description goes here\")?\nyear (default is \"2014\")?\nversion (default is \"0.1.0\")?", "title": "Running the initial cookiecutter command" }, { - "location": "/topics/third-party-resources/#getting-it-onto-github", + "location": "/topics/third-party-packages/#getting-it-onto-github", "text": "To put your project up on GitHub, you'll need a repository for it to live in. You can create a new repository here . If you need help, check out the Create A Repo article on GitHub.", "title": "Getting it onto GitHub" }, { - "location": "/topics/third-party-resources/#adding-to-travis-ci", + "location": "/topics/third-party-packages/#adding-to-travis-ci", "text": "We recommend using Travis CI , a hosted continuous integration service which integrates well with GitHub and is free for public repositories. To get started with Travis CI, sign in with your GitHub account. Once you're signed in, go to your profile page and enable the service hook for the repository you want. If you use the cookiecutter template, your project will already contain a .travis.yml file which Travis CI will use to build your project and run tests. By default, builds are triggered everytime you push to your repository or create Pull Request.", "title": "Adding to Travis CI" }, { - "location": "/topics/third-party-resources/#uploading-to-pypi", + "location": "/topics/third-party-packages/#uploading-to-pypi", "text": "Once you've got at least a prototype working and tests running, you should publish it on PyPI to allow others to install it via pip . You must register an account before publishing to PyPI. To register your package on PyPI run the following command. $ python setup.py register If this is the first time publishing to PyPI, you'll be prompted to login. Note: Before publishing you'll need to make sure you have the latest pip that supports wheel as well as install the wheel package. $ pip install --upgrade pip\n$ pip install wheel After this, every time you want to release a new version on PyPI just run the following command. $ python setup.py publish\nYou probably want to also tag the version now:\n git tag -a {0} -m 'version 0.1.0'\n git push --tags After releasing a new version to PyPI, it's always a good idea to tag the version and make available as a GitHub Release. We recommend to follow Semantic Versioning for your package's versions.", "title": "Uploading to PyPI" }, { - "location": "/topics/third-party-resources/#development", + "location": "/topics/third-party-packages/#development", "text": "", "title": "Development" }, { - "location": "/topics/third-party-resources/#version-requirements", + "location": "/topics/third-party-packages/#version-requirements", "text": "The cookiecutter template assumes a set of supported versions will be provided for Python and Django. Make sure you correctly update your requirements, docs, tox.ini , .travis.yml , and setup.py to match the set of versions you wish to support.", "title": "Version requirements" }, { - "location": "/topics/third-party-resources/#tests", + "location": "/topics/third-party-packages/#tests", "text": "The cookiecutter template includes a runtests.py which uses the pytest package as a test runner. Before running, you'll need to install a couple test requirements. $ pip install -r requirements.txt Once requirements installed, you can run runtests.py . $ ./runtests.py Run using a more concise output style. $ ./runtests.py -q Run the tests using a more concise output style, no coverage, no flake8. $ ./runtests.py --fast Don't run the flake8 code linting. $ ./runtests.py --nolint Only run the flake8 code linting, don't run the tests. $ ./runtests.py --lintonly Run the tests for a given test case. $ ./runtests.py MyTestCase Run the tests for a given test method. $ ./runtests.py MyTestCase.test_this_method Shorter form to run the tests for a given test method. $ ./runtests.py test_this_method To run your tests against multiple versions of Python as different versions of requirements such as Django we recommend using tox . Tox is a generic virtualenv management and test command line tool. First, install tox globally. $ pip install tox To run tox , just simply run: $ tox To run a particular tox environment: $ tox -e envlist envlist is a comma-separated value to that specifies the environments to run tests against. To view a list of all possible test environments, run: $ tox -l", "title": "Tests" }, { - "location": "/topics/third-party-resources/#version-compatibility", + "location": "/topics/third-party-packages/#version-compatibility", "text": "Sometimes, in order to ensure your code works on various different versions of Django, Python or third party libraries, you'll need to run slightly different code depending on the environment. Any code that branches in this way should be isolated into a compat.py module, and should provide a single common interface that the rest of the codebase can use. Check out Django REST framework's compat.py for an example.", "title": "Version compatibility" }, { - "location": "/topics/third-party-resources/#once-your-package-is-available", + "location": "/topics/third-party-packages/#once-your-package-is-available", "text": "Once your package is decently documented and available on PyPI, you might want share it with others that might find it useful.", "title": "Once your package is available" }, { - "location": "/topics/third-party-resources/#adding-to-the-django-rest-framework-grid", + "location": "/topics/third-party-packages/#adding-to-the-django-rest-framework-grid", "text": "We suggest adding your package to the REST Framework grid on Django Packages.", "title": "Adding to the Django REST framework grid" }, { - "location": "/topics/third-party-resources/#adding-to-the-django-rest-framework-docs", - "text": "Create a Pull Request or Issue on GitHub, and we'll add a link to it from the main REST framework documentation. You can add your package under Third party packages of the API Guide section that best applies, like Authentication or Permissions . You can also link your package under the Third Party Resources section.", + "location": "/topics/third-party-packages/#adding-to-the-django-rest-framework-docs", + "text": "Create a Pull Request or Issue on GitHub, and we'll add a link to it from the main REST framework documentation. You can add your package under Third party packages of the API Guide section that best applies, like Authentication or Permissions . You can also link your package under the Third Party Packages section.", "title": "Adding to the Django REST framework docs" }, { - "location": "/topics/third-party-resources/#announce-on-the-discussion-group", + "location": "/topics/third-party-packages/#announce-on-the-discussion-group", "text": "You can also let others know about your package through the discussion group .", "title": "Announce on the discussion group." }, { - "location": "/topics/third-party-resources/#existing-third-party-packages", + "location": "/topics/third-party-packages/#existing-third-party-packages", "text": "Django REST Framework has a growing community of developers, packages, and resources. Check out a grid detailing all the packages and ecosystem around Django REST Framework at Django Packages . To submit new content, open an issue or create a pull request .", "title": "Existing Third Party Packages" }, { - "location": "/topics/third-party-resources/#authentication", + "location": "/topics/third-party-packages/#authentication", "text": "djangorestframework-digestauth - Provides Digest Access Authentication support. django-oauth-toolkit - Provides OAuth 2.0 support. doac - Provides OAuth 2.0 support. djangorestframework-jwt - Provides JSON Web Token Authentication support. hawkrest - Provides Hawk HTTP Authorization. djangorestframework-httpsignature - Provides an easy to use HTTP Signature Authentication mechanism. djoser - Provides a set of views to handle basic actions such as registration, login, logout, password reset and account activation. django-rest-auth - Provides a set of REST API endpoints for registration, authentication (including social media authentication), password reset, retrieve and update user details, etc. drf-oidc-auth - Implements OpenID Connect token authentication for DRF.", "title": "Authentication" }, { - "location": "/topics/third-party-resources/#permissions", + "location": "/topics/third-party-packages/#permissions", "text": "drf-any-permissions - Provides alternative permission handling. djangorestframework-composed-permissions - Provides a simple way to define complex permissions. rest_condition - Another extension for building complex permissions in a simple and convenient way. dry-rest-permissions - Provides a simple way to define permissions for individual api actions.", "title": "Permissions" }, { - "location": "/topics/third-party-resources/#serializers", + "location": "/topics/third-party-packages/#serializers", "text": "django-rest-framework-mongoengine - Serializer class that supports using MongoDB as the storage layer for Django REST framework. djangorestframework-gis - Geographic add-ons djangorestframework-hstore - Serializer class to support django-hstore DictionaryField model field and its schema-mode feature. djangorestframework-jsonapi - Provides a parser, renderer, serializers, and other tools to help build an API that is compliant with the jsonapi.org spec. html-json-forms - Provides an algorithm and serializer to process HTML JSON Form submissions per the (inactive) spec. django-rest-framework-serializer-extensions -\n Enables black/whitelisting fields, and conditionally expanding child serializers on a per-view/request basis. djangorestframework-queryfields - Serializer mixin allowing clients to control which fields will be sent in the API response.", "title": "Serializers" }, { - "location": "/topics/third-party-resources/#serializer-fields", + "location": "/topics/third-party-packages/#serializer-fields", "text": "drf-compound-fields - Provides \"compound\" serializer fields, such as lists of simple values. django-extra-fields - Provides extra serializer fields. django-versatileimagefield - Provides a drop-in replacement for Django's stock ImageField that makes it easy to serve images in multiple sizes/renditions from a single field. For DRF-specific implementation docs, click here .", "title": "Serializer fields" }, { - "location": "/topics/third-party-resources/#views", + "location": "/topics/third-party-packages/#views", "text": "djangorestframework-bulk - Implements generic view mixins as well as some common concrete generic views to allow to apply bulk operations via API requests. django-rest-multiple-models - Provides a generic view (and mixin) for sending multiple serialized models and/or querysets via a single API request.", "title": "Views" }, { - "location": "/topics/third-party-resources/#routers", + "location": "/topics/third-party-packages/#routers", "text": "drf-nested-routers - Provides routers and relationship fields for working with nested resources. wq.db.rest - Provides an admin-style model registration API with reasonable default URLs and viewsets.", "title": "Routers" }, { - "location": "/topics/third-party-resources/#parsers", + "location": "/topics/third-party-packages/#parsers", "text": "djangorestframework-msgpack - Provides MessagePack renderer and parser support. djangorestframework-jsonapi - Provides a parser, renderer, serializers, and other tools to help build an API that is compliant with the jsonapi.org spec. djangorestframework-camel-case - Provides camel case JSON renderers and parsers.", "title": "Parsers" }, { - "location": "/topics/third-party-resources/#renderers", + "location": "/topics/third-party-packages/#renderers", "text": "djangorestframework-csv - Provides CSV renderer support. djangorestframework-jsonapi - Provides a parser, renderer, serializers, and other tools to help build an API that is compliant with the jsonapi.org spec. drf_ujson - Implements JSON rendering using the UJSON package. rest-pandas - Pandas DataFrame-powered renderers including Excel, CSV, and SVG formats.", "title": "Renderers" }, { - "location": "/topics/third-party-resources/#filtering", + "location": "/topics/third-party-packages/#filtering", "text": "djangorestframework-chain - Allows arbitrary chaining of both relations and lookup filters. django-url-filter - Allows a safe way to filter data via human-friendly URLs. It is a generic library which is not tied to DRF but it provides easy integration with DRF. drf-url-filter is a simple Django app to apply filters on drf ModelViewSet 's Queryset in a clean, simple and configurable way. It also supports validations on incoming query params and their values.", "title": "Filtering" }, { - "location": "/topics/third-party-resources/#misc", + "location": "/topics/third-party-packages/#misc", "text": "cookiecutter-django-rest - A cookiecutter template that takes care of the setup and configuration so you can focus on making your REST apis awesome. djangorestrelationalhyperlink - A hyperlinked serialiser that can can be used to alter relationships via hyperlinks, but otherwise like a hyperlink model serializer. django-rest-swagger - An API documentation generator for Swagger UI. django-rest-framework-proxy - Proxy to redirect incoming request to another API server. gaiarestframework - Utils for django-rest-framework drf-extensions - A collection of custom extensions ember-django-adapter - An adapter for working with Ember.js django-versatileimagefield - Provides a drop-in replacement for Django's stock ImageField that makes it easy to serve images in multiple sizes/renditions from a single field. For DRF-specific implementation docs, click here . drf-tracking - Utilities to track requests to DRF API views. drf_tweaks - Serializers with one-step validation (and more), pagination without counts and other tweaks. django-rest-framework-braces - Collection of utilities for working with Django Rest Framework. The most notable ones are FormSerializer and SerializerForm , which are adapters between DRF serializers and Django forms. drf-haystack - Haystack search for Django Rest Framework django-rest-framework-version-transforms - Enables the use of delta transformations for versioning of DRF resource representations. django-rest-messaging , django-rest-messaging-centrifugo and django-rest-messaging-js - A real-time pluggable messaging service using DRM.", "title": "Misc" }, { - "location": "/topics/third-party-resources/#other-resources", - "text": "", - "title": "Other Resources" + "location": "/topics/tutorials-and-resources/", + "text": "Tutorials and Resources\n\n\nThere are a wide range of resources available for learning and using Django REST framework. We try to keep a comprehensive list available here.\n\n\nTutorials\n\n\n\n\nBeginner's Guide to the Django REST Framework\n\n\nDjango REST Framework - An Introduction\n\n\nDjango REST Framework Tutorial\n\n\nDjango REST Framework Course\n\n\nBuilding a RESTful API with Django REST Framework\n\n\nGetting Started with Django REST Framework and AngularJS\n\n\nEnd to End Web App with Django REST Framework \n AngularJS\n\n\nStart Your API - Django REST Framework Part 1\n\n\nPermissions \n Authentication - Django REST Framework Part 2\n\n\nViewSets and Routers - Django REST Framework Part 3\n\n\nDjango REST Framework User Endpoint\n\n\nCheck Credentials Using Django REST Framework\n\n\nCreating a Production Ready API with Python and Django REST Framework \u2013 Part 1\n\n\nCreating a Production Ready API with Python and Django REST Framework \u2013 Part 2\n\n\n\n\nVideos\n\n\nTalks\n\n\n\n\nHow to Make a Full Fledged REST API with Django OAuth Toolkit\n\n\nDjango REST API - So Easy You Can Learn It in 25 Minutes\n\n\nTom Christie about Django Rest Framework at Django: Under The Hood\n\n\nDjango REST Framework: Schemas, Hypermedia \n Client Libraries\n\n\n\n\nTutorials\n\n\n\n\nDjango REST Framework Part 1\n\n\nDjango REST Framework in Your PJ's!\n\n\nBuilding a REST API Using Django \n Django REST Framework\n\n\nBlog API with Django REST Framework\n\n\nEmber and Django Part 1\n\n\nDjango REST Framework Image Upload Tutorial (with AngularJS)\n\n\nDjango REST Framework Tutorials\n\n\n\n\nArticles\n\n\n\n\nWeb API performance: Profiling Django REST Framework\n\n\nAPI Development with Django and Django REST Framework\n\n\nIntegrating Pandas, Django REST Framework and Bokeh\n\n\nControlling Uncertainty on Web Applications and APIs\n\n\nFull Text Search in Django REST Framework with Database Backends\n\n\nOAuth2 Authentication with Django REST Framework and Custom Third-Party OAuth2 Backends\n\n\nNested Resources with Django REST Framework\n\n\nImage Fields with Django REST Framework\n\n\nChatbot Using Django REST Framework + api.ai + Slack\u200a\u2014\u200aPart 1/3\n\n\nNew Django Admin with DRF and EmberJS... What are the News?\n\n\nBlog posts about Django REST Framework\n\n\n\n\nBooks\n\n\n\n\nHello Web App: Intermediate Concepts, Chapter 10\n\n\n\n\nDocumentations\n\n\n\n\nClassy Django REST Framework\n\n\nDRF-schema-adapter\n\n\n\n\nWant your Django REST Framework talk/tutorial/article to be added to our website? Or know of a resource that's not yet included here? Please \nsubmit a pull request\n or [email us][mailto:anna@django-rest-framework.org]!", + "title": "Tutorials and Resources" }, { - "location": "/topics/third-party-resources/#tutorials", - "text": "Beginner's Guide to the Django Rest Framework Getting Started with Django Rest Framework and AngularJS End to end web app with Django-Rest-Framework AngularJS Start Your API - django-rest-framework part 1 Permissions Authentication - django-rest-framework part 2 ViewSets and Routers - django-rest-framework part 3 Django Rest Framework User Endpoint Check credentials using Django Rest Framework Django REST Framework course", + "location": "/topics/tutorials-and-resources/#tutorials-and-resources", + "text": "There are a wide range of resources available for learning and using Django REST framework. We try to keep a comprehensive list available here.", + "title": "Tutorials and Resources" + }, + { + "location": "/topics/tutorials-and-resources/#tutorials", + "text": "Beginner's Guide to the Django REST Framework Django REST Framework - An Introduction Django REST Framework Tutorial Django REST Framework Course Building a RESTful API with Django REST Framework Getting Started with Django REST Framework and AngularJS End to End Web App with Django REST Framework AngularJS Start Your API - Django REST Framework Part 1 Permissions Authentication - Django REST Framework Part 2 ViewSets and Routers - Django REST Framework Part 3 Django REST Framework User Endpoint Check Credentials Using Django REST Framework Creating a Production Ready API with Python and Django REST Framework \u2013 Part 1 Creating a Production Ready API with Python and Django REST Framework \u2013 Part 2", "title": "Tutorials" }, { - "location": "/topics/third-party-resources/#videos", - "text": "Ember and Django Part 1 (Video) Django Rest Framework Part 1 (Video)", + "location": "/topics/tutorials-and-resources/#videos", + "text": "", "title": "Videos" }, { - "location": "/topics/third-party-resources/#articles", - "text": "Web API performance: profiling Django REST framework API Development with Django and Django REST Framework Blog posts about Django REST framework", + "location": "/topics/tutorials-and-resources/#talks", + "text": "How to Make a Full Fledged REST API with Django OAuth Toolkit Django REST API - So Easy You Can Learn It in 25 Minutes Tom Christie about Django Rest Framework at Django: Under The Hood Django REST Framework: Schemas, Hypermedia Client Libraries", + "title": "Talks" + }, + { + "location": "/topics/tutorials-and-resources/#tutorials_1", + "text": "Django REST Framework Part 1 Django REST Framework in Your PJ's! Building a REST API Using Django Django REST Framework Blog API with Django REST Framework Ember and Django Part 1 Django REST Framework Image Upload Tutorial (with AngularJS) Django REST Framework Tutorials", + "title": "Tutorials" + }, + { + "location": "/topics/tutorials-and-resources/#articles", + "text": "Web API performance: Profiling Django REST Framework API Development with Django and Django REST Framework Integrating Pandas, Django REST Framework and Bokeh Controlling Uncertainty on Web Applications and APIs Full Text Search in Django REST Framework with Database Backends OAuth2 Authentication with Django REST Framework and Custom Third-Party OAuth2 Backends Nested Resources with Django REST Framework Image Fields with Django REST Framework Chatbot Using Django REST Framework + api.ai + Slack\u200a\u2014\u200aPart 1/3 New Django Admin with DRF and EmberJS... What are the News? Blog posts about Django REST Framework", "title": "Articles" }, { - "location": "/topics/third-party-resources/#documentations", - "text": "Classy Django REST Framework", + "location": "/topics/tutorials-and-resources/#books", + "text": "Hello Web App: Intermediate Concepts, Chapter 10", + "title": "Books" + }, + { + "location": "/topics/tutorials-and-resources/#documentations", + "text": "Classy Django REST Framework DRF-schema-adapter Want your Django REST Framework talk/tutorial/article to be added to our website? Or know of a resource that's not yet included here? Please submit a pull request or [email us][mailto:anna@django-rest-framework.org]!", "title": "Documentations" }, { @@ -5509,6 +5534,21 @@ "location": "/topics/release-notes/#300", "text": "Date : 1st December 2014 For full details see the 3.0 release announcement . For older release notes, please see the version 2.x documentation .", "title": "3.0.0" + }, + { + "location": "/topics/jobs/", + "text": "Jobs\n\n\nLooking for a new Django REST Framework related role? On this site we provide a list of job resources that may be helpful. It's also worth checking out if any of \nour sponsors are hiring\n.\n\n\nPlaces to Look for Django REST Framework Jobs\n\n\n\n\nhttps://www.djangoproject.com/community/jobs/\n\n\nhttps://www.python.org/jobs/\n\n\nhttps://djangogigs.com\n\n\nhttps://djangojobs.net/jobs/\n\n\nhttp://djangojobbers.com\n\n\nhttps://www.indeed.com/q-Django-jobs.html\n\n\nhttp://stackoverflow.com/jobs/developer-jobs-using-django\n\n\nhttps://www.upwork.com/o/jobs/browse/skill/django-framework/\n\n\nhttps://www.technojobs.co.uk/django-jobs\n\n\nhttps://remoteok.io/remote-django-jobs\n\n\nhttps://www.remotepython.com/jobs/\n\n\n\n\nKnow of any other great resources for Django REST Framework jobs that are missing in our list? Please \nsubmit a pull request\n or [email us][mailto:anna@django-rest-framework.org].\n\n\nWonder how else you can help? One of the best ways you can help Django REST Framework is to ask interviewers if their company is signed up for \nREST Framework sponsorship\n yet.", + "title": "Jobs" + }, + { + "location": "/topics/jobs/#jobs", + "text": "Looking for a new Django REST Framework related role? On this site we provide a list of job resources that may be helpful. It's also worth checking out if any of our sponsors are hiring .", + "title": "Jobs" + }, + { + "location": "/topics/jobs/#places-to-look-for-django-rest-framework-jobs", + "text": "https://www.djangoproject.com/community/jobs/ https://www.python.org/jobs/ https://djangogigs.com https://djangojobs.net/jobs/ http://djangojobbers.com https://www.indeed.com/q-Django-jobs.html http://stackoverflow.com/jobs/developer-jobs-using-django https://www.upwork.com/o/jobs/browse/skill/django-framework/ https://www.technojobs.co.uk/django-jobs https://remoteok.io/remote-django-jobs https://www.remotepython.com/jobs/ Know of any other great resources for Django REST Framework jobs that are missing in our list? Please submit a pull request or [email us][mailto:anna@django-rest-framework.org]. Wonder how else you can help? One of the best ways you can help Django REST Framework is to ask interviewers if their company is signed up for REST Framework sponsorship yet.", + "title": "Places to Look for Django REST Framework Jobs" } ] } \ No newline at end of file diff --git a/sitemap.xml b/sitemap.xml index 9f5b8b517..010ffb716 100644 --- a/sitemap.xml +++ b/sitemap.xml @@ -4,7 +4,7 @@ http://www.django-rest-framework.org// - 2017-02-10 + 2017-02-25 daily @@ -13,49 +13,49 @@ http://www.django-rest-framework.org//tutorial/quickstart/ - 2017-02-10 + 2017-02-25 daily http://www.django-rest-framework.org//tutorial/1-serialization/ - 2017-02-10 + 2017-02-25 daily http://www.django-rest-framework.org//tutorial/2-requests-and-responses/ - 2017-02-10 + 2017-02-25 daily http://www.django-rest-framework.org//tutorial/3-class-based-views/ - 2017-02-10 + 2017-02-25 daily http://www.django-rest-framework.org//tutorial/4-authentication-and-permissions/ - 2017-02-10 + 2017-02-25 daily http://www.django-rest-framework.org//tutorial/5-relationships-and-hyperlinked-apis/ - 2017-02-10 + 2017-02-25 daily http://www.django-rest-framework.org//tutorial/6-viewsets-and-routers/ - 2017-02-10 + 2017-02-25 daily http://www.django-rest-framework.org//tutorial/7-schemas-and-client-libraries/ - 2017-02-10 + 2017-02-25 daily @@ -65,163 +65,163 @@ http://www.django-rest-framework.org//api-guide/requests/ - 2017-02-10 + 2017-02-25 daily http://www.django-rest-framework.org//api-guide/responses/ - 2017-02-10 + 2017-02-25 daily http://www.django-rest-framework.org//api-guide/views/ - 2017-02-10 + 2017-02-25 daily http://www.django-rest-framework.org//api-guide/generic-views/ - 2017-02-10 + 2017-02-25 daily http://www.django-rest-framework.org//api-guide/viewsets/ - 2017-02-10 + 2017-02-25 daily http://www.django-rest-framework.org//api-guide/routers/ - 2017-02-10 + 2017-02-25 daily http://www.django-rest-framework.org//api-guide/parsers/ - 2017-02-10 + 2017-02-25 daily http://www.django-rest-framework.org//api-guide/renderers/ - 2017-02-10 + 2017-02-25 daily http://www.django-rest-framework.org//api-guide/serializers/ - 2017-02-10 + 2017-02-25 daily http://www.django-rest-framework.org//api-guide/fields/ - 2017-02-10 + 2017-02-25 daily http://www.django-rest-framework.org//api-guide/relations/ - 2017-02-10 + 2017-02-25 daily http://www.django-rest-framework.org//api-guide/validators/ - 2017-02-10 + 2017-02-25 daily http://www.django-rest-framework.org//api-guide/authentication/ - 2017-02-10 + 2017-02-25 daily http://www.django-rest-framework.org//api-guide/permissions/ - 2017-02-10 + 2017-02-25 daily http://www.django-rest-framework.org//api-guide/throttling/ - 2017-02-10 + 2017-02-25 daily http://www.django-rest-framework.org//api-guide/filtering/ - 2017-02-10 + 2017-02-25 daily http://www.django-rest-framework.org//api-guide/pagination/ - 2017-02-10 + 2017-02-25 daily http://www.django-rest-framework.org//api-guide/versioning/ - 2017-02-10 + 2017-02-25 daily http://www.django-rest-framework.org//api-guide/content-negotiation/ - 2017-02-10 + 2017-02-25 daily http://www.django-rest-framework.org//api-guide/metadata/ - 2017-02-10 + 2017-02-25 daily http://www.django-rest-framework.org//api-guide/schemas/ - 2017-02-10 + 2017-02-25 daily http://www.django-rest-framework.org//api-guide/format-suffixes/ - 2017-02-10 + 2017-02-25 daily http://www.django-rest-framework.org//api-guide/reverse/ - 2017-02-10 + 2017-02-25 daily http://www.django-rest-framework.org//api-guide/exceptions/ - 2017-02-10 + 2017-02-25 daily http://www.django-rest-framework.org//api-guide/status-codes/ - 2017-02-10 + 2017-02-25 daily http://www.django-rest-framework.org//api-guide/testing/ - 2017-02-10 + 2017-02-25 daily http://www.django-rest-framework.org//api-guide/settings/ - 2017-02-10 + 2017-02-25 daily @@ -231,127 +231,139 @@ http://www.django-rest-framework.org//topics/documenting-your-api/ - 2017-02-10 + 2017-02-25 daily http://www.django-rest-framework.org//topics/api-clients/ - 2017-02-10 + 2017-02-25 daily http://www.django-rest-framework.org//topics/internationalization/ - 2017-02-10 + 2017-02-25 daily http://www.django-rest-framework.org//topics/ajax-csrf-cors/ - 2017-02-10 + 2017-02-25 daily http://www.django-rest-framework.org//topics/html-and-forms/ - 2017-02-10 + 2017-02-25 daily http://www.django-rest-framework.org//topics/browser-enhancements/ - 2017-02-10 + 2017-02-25 daily http://www.django-rest-framework.org//topics/browsable-api/ - 2017-02-10 + 2017-02-25 daily http://www.django-rest-framework.org//topics/rest-hypermedia-hateoas/ - 2017-02-10 + 2017-02-25 daily - http://www.django-rest-framework.org//topics/third-party-resources/ - 2017-02-10 + http://www.django-rest-framework.org//topics/third-party-packages/ + 2017-02-25 + daily + + + + http://www.django-rest-framework.org//topics/tutorials-and-resources/ + 2017-02-25 daily http://www.django-rest-framework.org//topics/contributing/ - 2017-02-10 + 2017-02-25 daily http://www.django-rest-framework.org//topics/project-management/ - 2017-02-10 + 2017-02-25 daily http://www.django-rest-framework.org//topics/3.0-announcement/ - 2017-02-10 + 2017-02-25 daily http://www.django-rest-framework.org//topics/3.1-announcement/ - 2017-02-10 + 2017-02-25 daily http://www.django-rest-framework.org//topics/3.2-announcement/ - 2017-02-10 + 2017-02-25 daily http://www.django-rest-framework.org//topics/3.3-announcement/ - 2017-02-10 + 2017-02-25 daily http://www.django-rest-framework.org//topics/3.4-announcement/ - 2017-02-10 + 2017-02-25 daily http://www.django-rest-framework.org//topics/3.5-announcement/ - 2017-02-10 + 2017-02-25 daily http://www.django-rest-framework.org//topics/kickstarter-announcement/ - 2017-02-10 + 2017-02-25 daily http://www.django-rest-framework.org//topics/mozilla-grant/ - 2017-02-10 + 2017-02-25 daily http://www.django-rest-framework.org//topics/funding/ - 2017-02-10 + 2017-02-25 daily http://www.django-rest-framework.org//topics/release-notes/ - 2017-02-10 + 2017-02-25 + daily + + + + http://www.django-rest-framework.org//topics/jobs/ + 2017-02-25 daily diff --git a/topics/3.0-announcement/index.html b/topics/3.0-announcement/index.html index 5cfdb2dc6..3333dfd42 100644 --- a/topics/3.0-announcement/index.html +++ b/topics/3.0-announcement/index.html @@ -271,7 +271,11 @@

  • - Third Party Resources + Third Party Packages +
    • + +
  • + Tutorials and Resources
  • @@ -322,6 +326,10 @@ Release Notes
    • +
  • + Jobs +
    • + diff --git a/topics/3.1-announcement/index.html b/topics/3.1-announcement/index.html index 594562db3..645570595 100644 --- a/topics/3.1-announcement/index.html +++ b/topics/3.1-announcement/index.html @@ -271,7 +271,11 @@
  • - Third Party Resources + Third Party Packages +
    • + +
  • + Tutorials and Resources
  • @@ -322,6 +326,10 @@ Release Notes
    • +
  • + Jobs +
    • + diff --git a/topics/3.2-announcement/index.html b/topics/3.2-announcement/index.html index 9345ca4e1..7dfc32c5a 100644 --- a/topics/3.2-announcement/index.html +++ b/topics/3.2-announcement/index.html @@ -271,7 +271,11 @@
  • - Third Party Resources + Third Party Packages +
    • + +
  • + Tutorials and Resources
  • @@ -322,6 +326,10 @@ Release Notes
    • +
  • + Jobs +
    • + diff --git a/topics/3.3-announcement/index.html b/topics/3.3-announcement/index.html index 396fbcb4d..fc0df5c0c 100644 --- a/topics/3.3-announcement/index.html +++ b/topics/3.3-announcement/index.html @@ -271,7 +271,11 @@
  • - Third Party Resources + Third Party Packages +
    • + +
  • + Tutorials and Resources
  • @@ -322,6 +326,10 @@ Release Notes
    • +
  • + Jobs +
    • + diff --git a/topics/3.4-announcement/index.html b/topics/3.4-announcement/index.html index a003fcdf1..c1b5de185 100644 --- a/topics/3.4-announcement/index.html +++ b/topics/3.4-announcement/index.html @@ -271,7 +271,11 @@
  • - Third Party Resources + Third Party Packages +
    • + +
  • + Tutorials and Resources
  • @@ -322,6 +326,10 @@ Release Notes
    • +
  • + Jobs +
    • + diff --git a/topics/3.5-announcement/index.html b/topics/3.5-announcement/index.html index 99af36450..18bb864e2 100644 --- a/topics/3.5-announcement/index.html +++ b/topics/3.5-announcement/index.html @@ -271,7 +271,11 @@
  • - Third Party Resources + Third Party Packages +
    • + +
  • + Tutorials and Resources
  • @@ -322,6 +326,10 @@ Release Notes
    • +
  • + Jobs +
    • + diff --git a/topics/ajax-csrf-cors/index.html b/topics/ajax-csrf-cors/index.html index 84c20ecf2..507701915 100644 --- a/topics/ajax-csrf-cors/index.html +++ b/topics/ajax-csrf-cors/index.html @@ -271,7 +271,11 @@
  • - Third Party Resources + Third Party Packages +
    • + +
  • + Tutorials and Resources
  • @@ -322,6 +326,10 @@ Release Notes
    • +
  • + Jobs +
    • + diff --git a/topics/api-clients/index.html b/topics/api-clients/index.html index a7677abdf..1edc5caf5 100644 --- a/topics/api-clients/index.html +++ b/topics/api-clients/index.html @@ -271,7 +271,11 @@
  • - Third Party Resources + Third Party Packages +
    • + +
  • + Tutorials and Resources
  • @@ -322,6 +326,10 @@ Release Notes
    • +
  • + Jobs +
    • + diff --git a/topics/browsable-api/index.html b/topics/browsable-api/index.html index ffb642472..7d3527ebe 100644 --- a/topics/browsable-api/index.html +++ b/topics/browsable-api/index.html @@ -271,7 +271,11 @@
  • - Third Party Resources + Third Party Packages +
    • + +
  • + Tutorials and Resources
  • @@ -322,6 +326,10 @@ Release Notes
    • +
  • + Jobs +
    • + diff --git a/topics/browser-enhancements/index.html b/topics/browser-enhancements/index.html index 9d5e8e75d..87c9c47f9 100644 --- a/topics/browser-enhancements/index.html +++ b/topics/browser-enhancements/index.html @@ -271,7 +271,11 @@
  • - Third Party Resources + Third Party Packages +
    • + +
  • + Tutorials and Resources
  • @@ -322,6 +326,10 @@ Release Notes
    • +
  • + Jobs +
    • + diff --git a/topics/contributing/index.html b/topics/contributing/index.html index dd231b15f..9203e44df 100644 --- a/topics/contributing/index.html +++ b/topics/contributing/index.html @@ -61,7 +61,7 @@ - Search @@ -271,7 +271,11 @@
  • - Third Party Resources + Third Party Packages +
    • + +
  • + Tutorials and Resources
  • @@ -322,6 +326,10 @@ Release Notes
    • +
  • + Jobs +
    • + diff --git a/topics/documenting-your-api/index.html b/topics/documenting-your-api/index.html index 96d896d34..83b243406 100644 --- a/topics/documenting-your-api/index.html +++ b/topics/documenting-your-api/index.html @@ -271,7 +271,11 @@
  • - Third Party Resources + Third Party Packages +
    • + +
  • + Tutorials and Resources
  • @@ -322,6 +326,10 @@ Release Notes
    • +
  • + Jobs +
    • + diff --git a/topics/funding/index.html b/topics/funding/index.html index 7232af04b..1380f7e0d 100644 --- a/topics/funding/index.html +++ b/topics/funding/index.html @@ -271,7 +271,11 @@
  • - Third Party Resources + Third Party Packages +
    • + +
  • + Tutorials and Resources
  • @@ -322,6 +326,10 @@ Release Notes
    • +
  • + Jobs +
    • + diff --git a/topics/html-and-forms/index.html b/topics/html-and-forms/index.html index 118ec9181..3364ccda9 100644 --- a/topics/html-and-forms/index.html +++ b/topics/html-and-forms/index.html @@ -271,7 +271,11 @@
  • - Third Party Resources + Third Party Packages +
    • + +
  • + Tutorials and Resources
  • @@ -322,6 +326,10 @@ Release Notes
    • +
  • + Jobs +
    • + diff --git a/topics/internationalization/index.html b/topics/internationalization/index.html index 6a79b2a92..a81ba664d 100644 --- a/topics/internationalization/index.html +++ b/topics/internationalization/index.html @@ -271,7 +271,11 @@
  • - Third Party Resources + Third Party Packages +
    • + +
  • + Tutorials and Resources
  • @@ -322,6 +326,10 @@ Release Notes
    • +
  • + Jobs +
    • + diff --git a/topics/jobs/index.html b/topics/jobs/index.html new file mode 100644 index 000000000..f9a7c1560 --- /dev/null +++ b/topics/jobs/index.html @@ -0,0 +1,466 @@ + + + + + + + Jobs - Django REST framework + + + + + + + + + + + + + + + + + + + + + +
    +
    +
    +
    + GitHub + + + Search + + + + + + Django REST framework +
    + + + + +
    + + +
    +
    +
    + +
    +
    + + + +
    +
    +
    + + +
    +
    + +
    + + + +

    Jobs

    +

    Looking for a new Django REST Framework related role? On this site we provide a list of job resources that may be helpful. It's also worth checking out if any of our sponsors are hiring.

    +

    Places to Look for Django REST Framework Jobs

    + +

    Know of any other great resources for Django REST Framework jobs that are missing in our list? Please submit a pull request or [email us][mailto:anna@django-rest-framework.org].

    +

    Wonder how else you can help? One of the best ways you can help Django REST Framework is to ask interviewers if their company is signed up for REST Framework sponsorship yet.

    + + +
    +
    +
    +
    +
    +
    + +
    +

    Documentation built with MkDocs. +

    +
    + + + + + + + + + + + + + + + \ No newline at end of file diff --git a/topics/kickstarter-announcement/index.html b/topics/kickstarter-announcement/index.html index b424ddbce..c1a797767 100644 --- a/topics/kickstarter-announcement/index.html +++ b/topics/kickstarter-announcement/index.html @@ -271,7 +271,11 @@
  • - Third Party Resources + Third Party Packages +
    • + +
  • + Tutorials and Resources
  • @@ -322,6 +326,10 @@ Release Notes
    • +
  • + Jobs +
    • + diff --git a/topics/mozilla-grant/index.html b/topics/mozilla-grant/index.html index 3247abd4c..056639216 100644 --- a/topics/mozilla-grant/index.html +++ b/topics/mozilla-grant/index.html @@ -271,7 +271,11 @@
  • - Third Party Resources + Third Party Packages +
    • + +
  • + Tutorials and Resources
  • @@ -322,6 +326,10 @@ Release Notes
    • +
  • + Jobs +
    • + diff --git a/topics/project-management/index.html b/topics/project-management/index.html index a511e926d..14deea605 100644 --- a/topics/project-management/index.html +++ b/topics/project-management/index.html @@ -271,7 +271,11 @@
  • - Third Party Resources + Third Party Packages +
    • + +
  • + Tutorials and Resources
  • @@ -322,6 +326,10 @@ Release Notes
    • +
  • + Jobs +
    • + diff --git a/topics/release-notes/index.html b/topics/release-notes/index.html index 7a7d737c4..9c020828b 100644 --- a/topics/release-notes/index.html +++ b/topics/release-notes/index.html @@ -58,7 +58,7 @@
    GitHub -
  • Third Party Resources + Third Party Packages +
    • + +
  • + Tutorials and Resources
  • @@ -322,6 +326,10 @@ Release Notes
    • +
  • + Jobs +
    • + diff --git a/topics/rest-hypermedia-hateoas/index.html b/topics/rest-hypermedia-hateoas/index.html index 81a5cdba7..2f1adb12f 100644 --- a/topics/rest-hypermedia-hateoas/index.html +++ b/topics/rest-hypermedia-hateoas/index.html @@ -58,7 +58,7 @@
    GitHub -
  • Third Party Resources + Third Party Packages +
    • + +
  • + Tutorials and Resources
  • @@ -322,6 +326,10 @@ Release Notes
    • +
  • + Jobs +
    • + diff --git a/topics/third-party-packages/index.html b/topics/third-party-packages/index.html new file mode 100644 index 000000000..484dcf6c4 --- /dev/null +++ b/topics/third-party-packages/index.html @@ -0,0 +1,655 @@ + + + + + + + Third Party Packages - Django REST framework + + + + + + + + + + + + + + + + + + + + + +
    +
    +
    +
    + GitHub + + + Search + + + + + + Django REST framework +
    + + + + +
    + + +
    +
    +
    + +
    +
    + + + +
    +
    + +
    + +
    + + + +

    Third Party Packages

    +
    +

    Software ecosystems […] establish a community that further accelerates the sharing of knowledge, content, issues, expertise and skills.

    +

    — Jan Bosch.

    +
    +

    About Third Party Packages

    +

    Third Party Packages allow developers to share code that extends the functionality of Django REST framework, in order to support additional use-cases.

    +

    We support, encourage and strongly favor the creation of Third Party Packages to encapsulate new behavior rather than adding additional functionality directly to Django REST Framework.

    +

    We aim to make creating third party packages as easy as possible, whilst keeping a simple and well maintained core API. By promoting third party packages we ensure that the responsibility for a package remains with its author. If a package proves suitably popular it can always be considered for inclusion into the core REST framework.

    +

    If you have an idea for a new feature please consider how it may be packaged as a Third Party Package. We're always happy to discuss ideas on the Mailing List.

    +

    How to create a Third Party Package

    +

    Creating your package

    +

    You can use this cookiecutter template for creating reusable Django REST Framework packages quickly. Cookiecutter creates projects from project templates. While optional, this cookiecutter template includes best practices from Django REST framework and other packages, as well as a Travis CI configuration, Tox configuration, and a sane setup.py for easy PyPI registration/distribution.

    +

    Note: Let us know if you have an alternate cookiecuter package so we can also link to it.

    +

    Running the initial cookiecutter command

    +

    To run the initial cookiecutter command, you'll first need to install the Python cookiecutter package.

    +
    $ pip install cookiecutter
+
    +

    Once cookiecutter is installed just run the following to create a new project.

    +
    $ cookiecutter gh:jpadilla/cookiecutter-django-rest-framework
+
    +

    You'll be prompted for some questions, answer them, then it'll create your Python package in the current working directory based on those values.

    +
    full_name (default is "Your full name here")? Johnny Appleseed
+email (default is "you@example.com")? jappleseed@example.com
+github_username (default is "yourname")? jappleseed
+pypi_project_name (default is "dj-package")? djangorestframework-custom-auth
+repo_name (default is "dj-package")? django-rest-framework-custom-auth
+app_name (default is "djpackage")? custom_auth
+project_short_description (default is "Your project description goes here")?
+year (default is "2014")?
+version (default is "0.1.0")?
+
    +

    Getting it onto GitHub

    +

    To put your project up on GitHub, you'll need a repository for it to live in. You can create a new repository here. If you need help, check out the Create A Repo article on GitHub.

    +

    Adding to Travis CI

    +

    We recommend using Travis CI, a hosted continuous integration service which integrates well with GitHub and is free for public repositories.

    +

    To get started with Travis CI, sign in with your GitHub account. Once you're signed in, go to your profile page and enable the service hook for the repository you want.

    +

    If you use the cookiecutter template, your project will already contain a .travis.yml file which Travis CI will use to build your project and run tests. By default, builds are triggered everytime you push to your repository or create Pull Request.

    +

    Uploading to PyPI

    +

    Once you've got at least a prototype working and tests running, you should publish it on PyPI to allow others to install it via pip.

    +

    You must register an account before publishing to PyPI.

    +

    To register your package on PyPI run the following command.

    +
    $ python setup.py register
+
    +

    If this is the first time publishing to PyPI, you'll be prompted to login.

    +

    Note: Before publishing you'll need to make sure you have the latest pip that supports wheel as well as install the wheel package.

    +
    $ pip install --upgrade pip
+$ pip install wheel
+
    +

    After this, every time you want to release a new version on PyPI just run the following command.

    +
    $ python setup.py publish
+You probably want to also tag the version now:
+    git tag -a {0} -m 'version 0.1.0'
+    git push --tags
+
    +

    After releasing a new version to PyPI, it's always a good idea to tag the version and make available as a GitHub Release.

    +

    We recommend to follow Semantic Versioning for your package's versions.

    +

    Development

    +

    Version requirements

    +

    The cookiecutter template assumes a set of supported versions will be provided for Python and Django. Make sure you correctly update your requirements, docs, tox.ini, .travis.yml, and setup.py to match the set of versions you wish to support.

    +

    Tests

    +

    The cookiecutter template includes a runtests.py which uses the pytest package as a test runner.

    +

    Before running, you'll need to install a couple test requirements.

    +
    $ pip install -r requirements.txt
+
    +

    Once requirements installed, you can run runtests.py.

    +
    $ ./runtests.py
+
    +

    Run using a more concise output style.

    +
    $ ./runtests.py -q
+
    +

    Run the tests using a more concise output style, no coverage, no flake8.

    +
    $ ./runtests.py --fast
+
    +

    Don't run the flake8 code linting.

    +
    $ ./runtests.py --nolint
+
    +

    Only run the flake8 code linting, don't run the tests.

    +
    $ ./runtests.py --lintonly
+
    +

    Run the tests for a given test case.

    +
    $ ./runtests.py MyTestCase
+
    +

    Run the tests for a given test method.

    +
    $ ./runtests.py MyTestCase.test_this_method
+
    +

    Shorter form to run the tests for a given test method.

    +
    $ ./runtests.py test_this_method
+
    +

    To run your tests against multiple versions of Python as different versions of requirements such as Django we recommend using tox. Tox is a generic virtualenv management and test command line tool.

    +

    First, install tox globally.

    +
    $ pip install tox
+
    +

    To run tox, just simply run:

    +
    $ tox
+
    +

    To run a particular tox environment:

    +
    $ tox -e envlist
+
    +

    envlist is a comma-separated value to that specifies the environments to run tests against. To view a list of all possible test environments, run:

    +
    $ tox -l
+
    +

    Version compatibility

    +

    Sometimes, in order to ensure your code works on various different versions of Django, Python or third party libraries, you'll need to run slightly different code depending on the environment. Any code that branches in this way should be isolated into a compat.py module, and should provide a single common interface that the rest of the codebase can use.

    +

    Check out Django REST framework's compat.py for an example.

    +

    Once your package is available

    +

    Once your package is decently documented and available on PyPI, you might want share it with others that might find it useful.

    +

    Adding to the Django REST framework grid

    +

    We suggest adding your package to the REST Framework grid on Django Packages.

    +

    Adding to the Django REST framework docs

    +

    Create a Pull Request or Issue on GitHub, and we'll add a link to it from the main REST framework documentation. You can add your package under Third party packages of the API Guide section that best applies, like Authentication or Permissions. You can also link your package under the Third Party Packages section.

    +

    Announce on the discussion group.

    +

    You can also let others know about your package through the discussion group.

    +

    Existing Third Party Packages

    +

    Django REST Framework has a growing community of developers, packages, and resources.

    +

    Check out a grid detailing all the packages and ecosystem around Django REST Framework at Django Packages.

    +

    To submit new content, open an issue or create a pull request.

    +

    Authentication

    +
      +
    • djangorestframework-digestauth - Provides Digest Access Authentication support.
      • +
    • django-oauth-toolkit - Provides OAuth 2.0 support.
      • +
    • doac - Provides OAuth 2.0 support.
      • +
    • djangorestframework-jwt - Provides JSON Web Token Authentication support.
      • +
    • hawkrest - Provides Hawk HTTP Authorization.
      • +
    • djangorestframework-httpsignature - Provides an easy to use HTTP Signature Authentication mechanism.
      • +
    • djoser - Provides a set of views to handle basic actions such as registration, login, logout, password reset and account activation.
      • +
    • django-rest-auth - Provides a set of REST API endpoints for registration, authentication (including social media authentication), password reset, retrieve and update user details, etc.
      • +
    • drf-oidc-auth - Implements OpenID Connect token authentication for DRF.
      • +
    +

    Permissions

    + +

    Serializers

    + +

    Serializer fields

    +
      +
    • drf-compound-fields - Provides "compound" serializer fields, such as lists of simple values.
      • +
    • django-extra-fields - Provides extra serializer fields.
      • +
    • django-versatileimagefield - Provides a drop-in replacement for Django's stock ImageField that makes it easy to serve images in multiple sizes/renditions from a single field. For DRF-specific implementation docs, click here.
      • +
    +

    Views

    +
      +
    • djangorestframework-bulk - Implements generic view mixins as well as some common concrete generic views to allow to apply bulk operations via API requests.
      • +
    • django-rest-multiple-models - Provides a generic view (and mixin) for sending multiple serialized models and/or querysets via a single API request.
      • +
    +

    Routers

    +
      +
    • drf-nested-routers - Provides routers and relationship fields for working with nested resources.
      • +
    • wq.db.rest - Provides an admin-style model registration API with reasonable default URLs and viewsets.
      • +
    +

    Parsers

    + +

    Renderers

    +
      +
    • djangorestframework-csv - Provides CSV renderer support.
      • +
    • djangorestframework-jsonapi - Provides a parser, renderer, serializers, and other tools to help build an API that is compliant with the jsonapi.org spec.
      • +
    • drf_ujson - Implements JSON rendering using the UJSON package.
      • +
    • rest-pandas - Pandas DataFrame-powered renderers including Excel, CSV, and SVG formats.
      • +
    +

    Filtering

    +
      +
    • djangorestframework-chain - Allows arbitrary chaining of both relations and lookup filters.
      • +
    • django-url-filter - Allows a safe way to filter data via human-friendly URLs. It is a generic library which is not tied to DRF but it provides easy integration with DRF.
      • +
    • drf-url-filter is a simple Django app to apply filters on drf ModelViewSet's Queryset in a clean, simple and configurable way. It also supports validations on incoming query params and their values.
      • +
    +

    Misc

    + + + +
    +
    +
    +
    +
    +
    + +
    +

    Documentation built with MkDocs. +

    +
    + + + + + + + + + + + + + + + \ No newline at end of file diff --git a/topics/tutorials-and-resources/index.html b/topics/tutorials-and-resources/index.html new file mode 100644 index 000000000..9c7a225be --- /dev/null +++ b/topics/tutorials-and-resources/index.html @@ -0,0 +1,521 @@ + + + + + + + Tutorials and Resources - Django REST framework + + + + + + + + + + + + + + + + + + + + + +
    +
    +
    +
    + GitHub + + + Search + + + + + + Django REST framework +
    + + + + +
    + + +
    +
    +
    + +
    +
    + + + +
    +
    +
    + + +
    +
    + +
    + + + +

    Tutorials and Resources

    +

    There are a wide range of resources available for learning and using Django REST framework. We try to keep a comprehensive list available here.

    +

    Tutorials

    + +

    Videos

    +

    Talks

    + +

    Tutorials

    + +

    Articles

    + +

    Books

    + +

    Documentations

    + +

    Want your Django REST Framework talk/tutorial/article to be added to our website? Or know of a resource that's not yet included here? Please submit a pull request or [email us][mailto:anna@django-rest-framework.org]!

    + + +
    +
    +
    +
    +
    +
    + +
    +

    Documentation built with MkDocs. +

    +
    + + + + + + + + + + + + + + + \ No newline at end of file diff --git a/tutorial/1-serialization/index.html b/tutorial/1-serialization/index.html index 46e49037f..28b24711d 100644 --- a/tutorial/1-serialization/index.html +++ b/tutorial/1-serialization/index.html @@ -271,7 +271,11 @@
  • - Third Party Resources + Third Party Packages +
    • + +
  • + Tutorials and Resources
  • @@ -322,6 +326,10 @@ Release Notes
    • +
  • + Jobs +
    • + diff --git a/tutorial/2-requests-and-responses/index.html b/tutorial/2-requests-and-responses/index.html index 720a6268e..481d62896 100644 --- a/tutorial/2-requests-and-responses/index.html +++ b/tutorial/2-requests-and-responses/index.html @@ -271,7 +271,11 @@
  • - Third Party Resources + Third Party Packages +
    • + +
  • + Tutorials and Resources
  • @@ -322,6 +326,10 @@ Release Notes
    • +
  • + Jobs +
    • + diff --git a/tutorial/3-class-based-views/index.html b/tutorial/3-class-based-views/index.html index c5fb41a1c..c0f7e771b 100644 --- a/tutorial/3-class-based-views/index.html +++ b/tutorial/3-class-based-views/index.html @@ -271,7 +271,11 @@
  • - Third Party Resources + Third Party Packages +
    • + +
  • + Tutorials and Resources
  • @@ -322,6 +326,10 @@ Release Notes
    • +
  • + Jobs +
    • + diff --git a/tutorial/4-authentication-and-permissions/index.html b/tutorial/4-authentication-and-permissions/index.html index d932ce373..2f1553481 100644 --- a/tutorial/4-authentication-and-permissions/index.html +++ b/tutorial/4-authentication-and-permissions/index.html @@ -271,7 +271,11 @@
  • - Third Party Resources + Third Party Packages +
    • + +
  • + Tutorials and Resources
  • @@ -322,6 +326,10 @@ Release Notes
    • +
  • + Jobs +
    • + diff --git a/tutorial/5-relationships-and-hyperlinked-apis/index.html b/tutorial/5-relationships-and-hyperlinked-apis/index.html index 78dd2723a..4c1f08a95 100644 --- a/tutorial/5-relationships-and-hyperlinked-apis/index.html +++ b/tutorial/5-relationships-and-hyperlinked-apis/index.html @@ -271,7 +271,11 @@
  • - Third Party Resources + Third Party Packages +
    • + +
  • + Tutorials and Resources
  • @@ -322,6 +326,10 @@ Release Notes
    • +
  • + Jobs +
    • + diff --git a/tutorial/6-viewsets-and-routers/index.html b/tutorial/6-viewsets-and-routers/index.html index dcbb453c1..6cf6590c3 100644 --- a/tutorial/6-viewsets-and-routers/index.html +++ b/tutorial/6-viewsets-and-routers/index.html @@ -271,7 +271,11 @@
  • - Third Party Resources + Third Party Packages +
    • + +
  • + Tutorials and Resources
  • @@ -322,6 +326,10 @@ Release Notes
    • +
  • + Jobs +
    • + diff --git a/tutorial/7-schemas-and-client-libraries/index.html b/tutorial/7-schemas-and-client-libraries/index.html index 6a694a86f..d6dcfe960 100644 --- a/tutorial/7-schemas-and-client-libraries/index.html +++ b/tutorial/7-schemas-and-client-libraries/index.html @@ -271,7 +271,11 @@
  • - Third Party Resources + Third Party Packages +
    • + +
  • + Tutorials and Resources
  • @@ -322,6 +326,10 @@ Release Notes
    • +
  • + Jobs +
    • + diff --git a/tutorial/quickstart/index.html b/tutorial/quickstart/index.html index b42f14f6f..3d96f4865 100644 --- a/tutorial/quickstart/index.html +++ b/tutorial/quickstart/index.html @@ -271,7 +271,11 @@
  • - Third Party Resources + Third Party Packages +
    • + +
  • + Tutorials and Resources
  • @@ -322,6 +326,10 @@ Release Notes
    • +
  • + Jobs +
    • +