予備知識
前提条件：CBVとFBVのジャンゴ
CBV（クラスベースビュー）：多目的、簡単にリコール
FBV（機能ベースのビュー）：
操作のCBVモードはシンプルで、ランディングページ、それに
次のようにlogin.htmlに文書が読み取ります。
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Title</title>
</head>
<body>
<form action="{% url 'login' %}" method="post">
{% csrf_token %}
用户名: <input type="text" name="username">
密码: <input type="text" name="password">
<input type="submit">
</form>
</body>
</html>url.pyは、以下の
from django.conf.urls import url
from django.contrib import admin
from app01 import views
urlpatterns = [
url(r'^admin/', admin.site.urls),
url(r'^login/', views.LoginView.as_view(),name='login'),
]views.py
from django.shortcuts import render,HttpResponse,redirect
# Create your views here.
from django.views import View
class LoginView(View):
def get(self,request):
return render(request,'login.html')
def post(self,request):
return HttpResponse('post')我々はまだどこから、ソースコードを、あなたを見て、なぜ、ポスト方法を見つけるためにポストの要求をgetメソッドのクラスを見つけるための要求は、順番にと遊ぶためにどのように分布への発送は、内部的なアプローチがある取得、ビュー機能CBVを覚えていますそれを参照してください？見た目にどこに最初が行われます
views.LoginView.as_view（）このことは、URLが要求を受信すると、それが呼び出すことはありません、最初の実行ああではないas_view（）クラスメソッドは、このメソッドはあなたのビューと呼ばれるリターンクラスのメソッドを与え、URLへの対応ユーザーがログインページにアクセスし、この方法のビューが、ビュー（リクエスト）が実行されていない、あなたはそれのソースを見て行きます。
その後、発送方法を再生し、コードを見ることができます：
from django.shortcuts import render,HttpResponse,redirect
# Create your views here.
from django.views import View
class LoginView(View):
def dispatch(self, request, *args, **kwargs):
print('something...')
res = super().dispatch(request, *args, **kwargs) #注意，不用传self，为什么呢，因为super已经帮你吧self放进去啦
print('someting....')
return res
def get(self,request):
return render(request,'login.html')
def post(self,request):
return HttpResponse('post')私たちのDRF学習の背中が、それを使用する必要があるため、なぜ、それを言います。
二つの安らかな仕様
抜粋：http://www.ruanyifeng.com/blog/2014/05/restful_api.html
1. RESTfulな何ですか
RESTfulなは、 Webデータ・インタフェースの設計のための最も人気のあるAPIの設計仕様です。
RESTは技術とは何の関係もない、ソフトウェアアーキテクチャのスタイルを表現し、RESTはのRepresentational State転送短く、中国の訳語として「状態の転送が特徴」
そのURLによるノードのネットワーク内のリソースの配分で識別されるネットワーク全体の資源の観点から、のようなRESTの外観は、リソースを取得するためのクライアント・アプリケーションは、URLによって特徴づけ、これらのアプリケーションへのアクセスは、結果の変更にこれらの状態を特徴づけます
データのすべてが、ネットワークや操作（CRUD）データ、すべてのリソースに買収された、すべてのデータは、RESTリソースが他の建築様式から最も重要な属性は異なるとして扱われます
このリソース指向のRESTアーキテクチャスタイルのために、それが示唆された新しい構造の概念、すなわち：リソース指向アーキテクチャ（ROA：リソース指向アーキテクチャ）
理解するには、2つの他、簡単なもあります。
远程过程调用（RPC）
远程过程调用为 Web 服务提供一个分布式函数/方法接口供用户调用。这是一种较传统的方式。通常，在 WSDL 中对 RPC 接口进行定义（类似于早期的XML-RPC）。本质上，RPC 方式利用一个简单映射，把用户请求直接转化成一个特定语言编写的函数/方法。现在，该方式已不再使用。
面向服务架构（SOA）
面向服务架构现在，业界比较关注的是遵从面向服务架构（Service-oriented architecture，SOA）来构建 Web 服务。该方式中，通讯是由消息驱动，而不再是某个动作（方法调用）。这种 Web 服务也称为“面向消息的服务”。Webアプリケーションは、2つのフロント及び後端部に分割されています。現在の傾向は、フロントエンド・デバイス（携帯電話、タブレット、デスクトップコンピュータ、その他の機器を......）浮上しています。
したがって、バックエンドと通信するために異なるフロントエンド装置を容易に均一なメカニズムが存在しなければなりません。これは、人気の高いAPIアーキテクチャにつながった、とさえ「APIまず」デザイン哲学。RESTfulなAPIは、インターネットアプリケーションのAPIの設計理論より成熟したセットです。あり、「RESTfulなアーキテクチャの理解」このコンセプトを理解するための方法を模索するためには。
状態遷移図の特性：
2.RESTFUl APIの設計
2.1使用契約
APIおよびユーザの通信プロトコルは、常に使用してHTTPSプロトコルを。
2.2は、ドメイン名を使用しています
APIは、専用サーバーのAPIを作成することを意味するプライベートドメイン名の下に展開されるようにしてください。
https://api.example.comそれは決定APIは非常に簡単ですされている場合は、それ以上の延長は行われませんメインのドメイン名の下に置かれたと考えることができます。
https://example.org/api/2.3バージョンのヒント
APIサイトが更新されている可能性があり、APIのバージョン番号はURLに配置する必要があります。
https://api.example.com/v1/別のアプローチではなく、便利で直感的なURLへとして、HTTPヘッダ情報内のバージョン番号です。githubのこの練習を。
2.4パスの言葉遣い
パスは、また、「終わり」（終点）として知られている、特定のURLのAPIを表しています。
RESTfulなアーキテクチャでは、各URLは、URLが名詞のみ、動詞を持つことができないので、資源（リソース）を表すだけでなく、この用語を使用することが多いデータベーステーブルの名前に対応します。APIはまた、複数の名詞を使用する必要がありますので、一般的には、データベース内のテーブルには、レコードの「コレクション」（コレクション）の同じ種類です。
例えば、動物および従業員の各種情報を含む更なる情報動物園（動物園）、提供するAPIがあり、それは、以下のパスに設計されるべきです。
https://api.example.com/v1/zoos
https://api.example.com/v1/animals
https://api.example.com/v1/employees2.5 HTTP動詞
HTTP動詞で表される動作の特定のリソースタイプについては、動詞は、処理およびその他の操作、ビューロジック処理とデータ処理、抽出に対応する分布関数の後端部へのアプローチの要求に基づいて、モードを要求するが、URL動詞発生することができません。
一般的なHTTP動詞は（括弧内の対応するSQLコマンドである）5以下の通りです。
GET（SELECT）：从服务器取出资源（一项或多项）。
POST（CREATE）：在服务器新建一个资源。
PUT（UPDATE）：在服务器更新资源（客户端提供改变后的完整资源）。
PATCH（UPDATE）：在服务器更新资源（客户端提供改变的属性，更新部分资源的意思）。他和put用哪个都可以，没有太大的区别，我们用put方式偏多
DELETE（DELETE）：从服务器删除资源。2つのあまり一般的に使用されるHTTP動詞があります。
HEAD：获取资源的元数据。
OPTIONS：获取信息，关于资源的哪些属性是客户端可以改变的 ここではいくつかの例があります。RESTfulな核となるアイデアは、クライアントのデータ操作命令が「動詞+オブジェクト」構造を発行していることです。たとえば、GET /articlesこのコマンドはGET、動詞である/articlesオブジェクトです。HTTPの仕様によると、動詞は資産計上されます。
GET /zoos：列出所有动物园
POST /zoos：新建一个动物园
GET /zoos/ID：获取某个指定动物园的信息
PUT /zoos/ID：更新某个指定动物园的信息（提供该动物园的全部信息）
PATCH /zoos/ID：更新某个指定动物园的信息（提供该动物园的部分信息）
DELETE /zoos/ID：删除某个动物园
GET /zoos/ID/animals：列出某个指定动物园的所有动物
DELETE /zoos/ID/animals/ID：删除某个指定动物园的指定动物動詞カバレッジ：
一部のクライアントのみを使用GETし、POST両方の方法。サーバは受け入れなければならないPOSTアナログ他の三つの方法をPUT（PATCH、DELETE）。
このとき、HTTPリクエストを追加するために、クライアントから送信されたX-HTTP-Method-Overrideカバーに使用すべきか動詞の属性は、サーバーに指示POSTする方法。
POST /api/Person/4 HTTP/1.1
X-HTTP-Method-Override: PUT 上記のコードでは、X-HTTP-Method-Override指定されたメソッドは、この要求であるPUT代わりに、POST。
オブジェクトの名前である必要があります。
オブジェクトは、HTTP URLのAPIである動詞アクションの目的です。これは、名詞、動詞ではないはずです。例えば、/articlesURLが正しいですが、以下のURLは名詞ではない、それは間違っています。
/getAllCars
/createNewCar
/deleteAllRedCarsURLは名詞であるので、あなたは、複数または単数を使用する必要がありますか？
これには、均一な要件ではありませんが、一般的な操作のような、コレクションを読み取ることであるGET /articles（すべての記事を読んで）、明らかに複数があるはずです。
一貫性のため、などの提案された使用の複雑なURLについては、GET /articles/2より良いですGET /article/2。
2.6情報フィルタリング（濾過、また、クエリパラメータとしても知られます）
多数のレコード場合は、サーバーはすべて彼らがユーザに返されることはできません。APIは、結果が返されるフィルタリング、パラメータを提供する必要があります。
ここではいくつかの共通のパラメータがあります。
?limit=10：指定返回记录的数量
?offset=10：指定返回记录的开始位置。
?page=2&per_page=100：指定第几页，以及每页的记录数。
?sortby=name&order=asc：指定返回结果按照哪个属性排序，以及排序顺序。
?animal_type_id=1：指定筛选条件冗長性は、設計パラメータは、すなわち、パラメータがAPIとURLパス時折、重複を許可することができます。たとえば、GET /動物園/ ID /動物とGET /動物？Zoo_id = IDは同じ意味です。
一般的な状況では、そのようないくつかの記事の著者へのアクセスとして、マルチレベルのURLを記述するのは簡単ですので、リソースは、マルチレベルの分類に必要があるということです。
GET /authors/12/categories/2このURLはセマンティクスが意味を理解するために、しばらくの間、順番に、多くの場合、明確ではないが、拡大に資するものです。
いっそのことは、最初のレベルに加えて、他のレベルは、クエリ文字列表現を使用しています。
GET /authors/12?categories=2
ここでもう一つの例は、クエリ掲載された記事です。あなたは、次のURLに設計することができます。
GET /articles/published
著しく良好なクエリ文字列表現
GET /articles?published=true
2.7ステータスコード
2.7.1ステータスコードは正確でなければなりません
各要求のカスタマー終わり、サーバーは応答を与えられなければなりません。レスポンスのHTTPステータスコードは二つの部分とデータを備えます。
HTTPステータスコードは、5つのカテゴリーに分け、3桁の数です。
1xx：相关信息
2xx：操作成功
3xx：重定向
4xx：客户端错误
5xx：服务器错误
これは、の5つのカテゴリーの合計が含まれ100種類の直面する可能性のある状況の大半をカバーし、ステータスコードを。各ステータスコードが標準（または合意されたが）、クライアントは単にステータスコードを確認することを説明した、サーバーが正確に可能な限り、ステータスコードとして返す必要がありますので、何が起こったのかを判断することができます。
必要としないAPI 1xxステータスコードは、以下のステータスコードの他の4つの正確な意味を説明しています。
2.7.2の2xxステータスコード
200ステータスコードは、動作を示しますが、異なる方法がより正確にステータスコードを返すことができます。
GET: 200 OK
POST: 201 Created
PUT: 200 OK
PATCH: 200 OK
DELETE: 204 No Content
上記のコードでは、POSTそれを返し201、ステータス新しいリソースを生成示すコードDELETE戻る204存在しないリソースを示すステータスコード。
さらに、202 Acceptedステータスコードは、サーバが要求を受信したことを示しているが、まだ処理されていない、処理が正常に非同期動作のために使用される、将来的にさらにあろう。ここでは一例です。
HTTP/1.1 202 Accepted
{
"task": {
"href": "/api/company/job-management/jobs/2130040",
"id": "2130040"
}
}
2.7.3の3xxステータスコード
API未満301ステータスコード（永続的なリダイレクト）と302ステータスコード（一時的なリダイレクト、307彼らはアプリケーションレベルで返すことができるので、ほかの意味）、ブラウザが直接ジャンプします、APIレベルは、これらの2つの場合を考慮することはできません。
API使用3xxステータスコードは、主に303 See Other、別のURLへの参照を表します。これ302と307同じような意味、「一時的なリダイレクト、」違いがそれである302、と307のためのGET要求、および303ためPOST、PUTとDELETE要求。受信した303後に、ブラウザが自動的にジャンプし、ユーザーが次に何をするかを決めることはできません。ここでは一例です。
HTTP/1.1 303 See Other
Location: /api/orders/12345
2.7.4 4xxのステータスコード
4xxステータスコードは、クライアントのエラーを示し、次のカテゴリです。
400 Bad Request：服务器不理解客户端的请求，未做任何处理。
401 Unauthorized：用户未提供身份验证凭据，或者没有通过身份验证。
403 Forbidden：用户通过了身份验证，但是不具有访问资源所需的权限。
404 Not Found：所请求的资源不存在，或不可用。
405 Method Not Allowed：用户已经通过身份验证，但是所用的 HTTP 方法不在他的权限之内。
410 Gone：所请求的资源已从这个地址转移，不再可用。
415 Unsupported Media Type：客户端要求的返回格式不支持。比如，API 只能返回 JSON 格式，但是客户端要求返回 XML 格式。
422 Unprocessable Entity ：客户端上传的附件无法处理，导致请求失败。
429 Too Many Requests：客户端的请求次数超过限额。
2.7.5 5xxのステータスコード
5xxステータスコードは、サーバーのエラーことを示しています。一般的には、APIサーバーの詳細は限り2つのステータスコードが十分であるとして、利用者に開示することはありません。
500 Internal Server Error：客户端请求有效，服务器处理时发生了意外。
503 Service Unavailable：服务器无法处理请求，一般用于网站维护状态。
一般的なステータスコードとそれに対応する記述をまとめます
200 OK - [GET]：服务器成功返回用户请求的数据，该操作是幂等的（Idempotent）。
201 CREATED - [POST/PUT/PATCH]：用户新建或修改数据成功。
202 Accepted - [*]：表示一个请求已经进入后台排队（异步任务）
204 NO CONTENT - [DELETE]：用户删除数据成功。301 状态码（永久重定向）302 状态码（暂时重定向，307也是这个含义）
400 INVALID REQUEST - [POST/PUT/PATCH]：用户发出的请求有错误，服务器没有进行新建或修改数据的操作，该操作是幂等的。
401 Unauthorized - [*]：表示用户没有权限（令牌、用户名、密码错误）。
403 Forbidden - [*] 表示用户得到授权（与401错误相对），但是访问是被禁止的。
404 NOT FOUND - [*]：用户发出的请求针对的是不存在的记录，服务器没有进行操作，该操作是幂等的。
406 Not Acceptable - [GET]：用户请求的格式不可得（比如用户请求JSON格式，但是只有XML格式）。
410 Gone -[GET]：用户请求的资源被永久删除，且不会再得到的。
422 Unprocesable entity - [POST/PUT/PATCH] 当创建一个对象时，发生一个验证错误。
500 INTERNAL SERVER ERROR - [*]：服务器发生错误，用户将无法判断发出的请求是否成功。
更多看这里：http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
2.8サーバーの応答
2.8.1データフォーマット対応
それは構造化データの標準に戻すことができるので、APIが返すデータの形式は、プレーンテキストではなく、JSONオブジェクトではありません。したがって、HTTPヘッダとサーバ応答Content-Type性を設定しますapplication/json。
ときにクライアント要求JSON形式を受け入れることができ、それは明らかにサーバーに指示する必要があり、すなわち、HTTPリクエストヘッダのACCEPT属性がに設定する必要がありますapplication/json。ここでは一例です。
GET /orders/2 HTTP/1.1
Accept: application/json
2.8.2応答エラーが発生
エラーが発生したときに、応答ステータスコード200、アプローチが存在しないエラーが発生しても、不適切であり、それは戻り200ステータスコード、次のような体内のデータにエラーメッセージを。
HTTP/1.1 200 OK
Content-Type: application/json
{
"status": "failure",
"data": {
"error": "Expected at least two items in list."
}
}
上記のコードでは、データ本体を解析した後に、動作を知るために失敗しました。
このような行為は完全に望ましくない事実キャンセルステータスコード、です。正しいアプローチは、であり、ステータスコード、エラーが発生した体内に戻されたデータのエラー特定情報を反映します。ここでは一例です。
HTTP/1.1 400 Bad Request
Content-Type: application/json
{
"error": "Invalid payoad.",
"detail": {
"surname": "This field is required."
}
}
2.8.3応答結果
別の操作については、サーバーにユーザーから返された結果は、以下の仕様を満たす必要があります。
GET /collection：返回资源对象的列表（数组），一般是[{"id":1,"name":"a",},{"id":2,name:"b"},]这种类型
GET /collection/resource：返回单个资源对象， 一般是查看的单条数据 {"id":1,"name":'a'}
POST /collection：返回新生成的资源对象 ， 一般是返回新添加的数据信息， 格式一般是{}
PUT /collection/resource：返回完整的资源对象 一般时返回更新后的数据，{}
PATCH /collection/resource：返回完整的资源对象
DELETE /collection/resource：返回一个空文档 一般返回一个空字符串
例えば：
2.9ハイパーメディアAPI提供のリンク
RESTfulなAPIはハイパーメディアを行うのがベストです、つまり、返された結果がリンクを提供し、ユーザーはAPIを知らないかもしれない、URLがどのようなデザインです。一つの解決策は、応答して、次のステップを容易にするためのリンクを与えられていることです。この場合、ユーザーはちょうどあなたが他のURLを見つけることができ、URLを覚えています。このメソッドは、HATEOASと呼ばれています。
举例来说，GitHub 的 API 都在 api.github.com 这个域名。访问它，就可以得到其他 URL。
{
...
"feeds_url": "https://api.github.com/feeds",
"followers_url": "https://api.github.com/user/followers",
"following_url": "https://api.github.com/user/following{/target}",
"gists_url": "https://api.github.com/gists{/gist_id}",
"hub_url": "https://api.github.com/hub",
...
}
上面的回应中，挑一个 URL 访问，又可以得到别的 URL。对于用户来说，不需要记住 URL 设计，只要从 api.github.com 一步步查找就可以了。
HATEOAS 的格式没有统一规定，上面例子中，GitHub 将它们与其他属性放在一起。更好的做法应该是，将相关链接与其他属性分开。
HTTP/1.1 200 OK
Content-Type: application/json
{
"status": "In progress",
"links": {[
{ "rel":"cancel", "method": "delete", "href":"/api/status/12345" } ,
{ "rel":"edit", "method": "put", "href":"/api/status/12345" }
]}
}
再比如：当用户向api.example.com的根目录发出请求，会得到这样一个文档。
{"link": {
"rel": "collection https://www.example.com/zoos",
"href": "https://api.example.com/zoos",
"title": "List of zoos",
"type": "application/vnd.yourformat+json"
}}
上面代码表示，文档中有一个links属性，用户读取这个属性就知道下一步该调用什么API了。rel表示这个API与当前网址的关系（collection关系，并给出该collection的网址），href表示API的路径，title表示API的标题，type表示返回类型。
2.10 其他
（1）API的身份认证应该使用OAuth 2.0框架。
（2）服务器返回的数据格式，应该尽量使用JSON，避免使用XML。
三 Django RestFramework(简称DRF)
drf是django发展来的一个符合restful接口规范的一个东西，啥东西呢，就是django的一个app，还记得app是啥不。DRF官网地址，但是大家记住一句话，即便是没有这drf，我们照样能做前后端分离的项目，自己做规范的数据接口，返回json数据，都是没问题的昂，那为什么还用drf啊，这个更nb。
在官网中我们看一下这里：
首先下载安装，django是必须要的，不过咱们的django已经下载好了，如果没下载好，那么pip install django，执行一下：
pip install django
pip install djangorestframework //执行这句话，下载drf
# Set up a new project with a single application
django-admin startproject tutorial . # Note the trailing '.' character
cd tutorial
django-admin startapp quickstart
cd ..
1.先基于djangoCBV，不用DRF来写个接口，看看效果
好，接下来我们创建一个django项目，models中创建一个表，添加一些数据，然后写一个数据接口来获取一下这些数据，返回json数据类型，按照我们CBV的模式来写，但是下面还没有用到我们的drf昂，只是告诉大家，没有drf，你也能做。
views.py文件内容如下：
from django.shortcuts import render,HttpResponse,redirect
import json
# Create your views here.
from django.views import View
from app01 import models
class CourseView(View):
def get(self,request):
#拿到queryset类型的数据，要加工成[{},{}]这种数据类型
course_obj_list = models.Course.objects.all()
ret = []
for course_obj in course_obj_list:
ret.append({
"title":course_obj.title,
"desc":course_obj.desc,
})
return HttpResponse(json.dumps(ret,ensure_ascii=False)) #ensure_ascii=False是告诉json不要对中文进行编码，不然返回给前端的数据中如果有中文的话会被编码成unicode类型的数据，导致前端看不到中文
urls.py内容如下：
from django.conf.urls import url
from django.contrib import admin
from app01 import views
urlpatterns = [
#url(r'^admin/', admin.site.urls),
url(r'^courses/', views.CourseView.as_view(),name='courses'), #接口就写好啦
]
然后启动项目，在浏览器中一访问，就看到了我们后端返回的json数据：
有人就又说了，我们这么写也ok啊，要drf干嘛，上面这个例子是个简单的例子，数据简单、逻辑简单，你这样写当然看着没有问题啦，但是数据量很大，结构很复杂的时候，你这样写的时候就头疼了。
所以上面这个例子你就作为了解吧，我们玩一下drf。
玩DRF之前，我们先说一下我们DRF中有哪些内容：
咱们玩下面10个组件： a.APIView (*****)
b.序列化组件 (*****)
c.试图类(mixin) (*****)
d.认证组件 (*****)
e.权限组件
f.频率组件
g.分页组件
h.解析器组件 (*****)
i.相应其组件
j.url控制器
2.基于DRF来写接口
2.1 APIView组件
在我们的视图中，通过CBV来写视图的时候，继承APIView，url不变，还是上面那个，通过浏览器访问，照样能够看到我们返回的数据，
views.py内容如下：
from django.shortcuts import render,HttpResponse,redirect
import json
from django.views import View
from app01 import models
#引入APIView,APIView是继承的django的View，也就是APIView在View的基础上添加了一些其他的功能
from rest_framework.views import APIView
class CourseView(APIView):
def get(self,request):
course_obj_list = models.Course.objects.all()
ret = []
for course_obj in course_obj_list:
ret.append({
"title":course_obj.title,
"desc":course_obj.desc,
})
return HttpResponse(json.dumps(ret, ensure_ascii=False))
urls.py内容如下：
from django.conf.urls import url
from django.contrib import admin
from app01 import views
urlpatterns = [
url(r'^admin/', admin.site.urls),
url(r'^courses/', views.CourseView.as_view(),name='courses'),
]
页面访问url效果：
照样拿到了数据，那么怎么回事儿呢，我们看源码，知道一下APIView的流程就行。
2.2 解析器组件
知识准备，还记得一个叫做contentType的http请求头的东西吗？回想一下。
后端根据contentType的类型来找到对应的解析数据的方法来解析数据，提取数据
但是django没有内置的自动解开json数据类型的方法，那么只能去request.body里面拿原始的bytes类型的数据，然后自己解，其实很简单，但是django没有，可能是早先没有考虑到。
contentTypeの、データrequest.POSTメソッド内に置くことができ、その後mutipart /フォームデータとファイルデータでurlencodeの種類、およびあるソリューションジャンゴパーサによって呼び出され、それらを解決するための自動データをジャンゴ。
def post(self,request):
print(request.POST)
print(type(request)) #通过这个对象的类型(类对象)，找到它的源码看看
return HttpResponse('POST')
自分のパーサによってDRF、私たちは身体データ要求を取得し、パッケージrequest.dataプロパティを要求するためにどの助け、その後、実質的に解析し、パーサがデータ型のすべてを解析することができますが、自動的にジャンゴを含んで解決できませんJSONデータ型、我々はそれをデバッグし、結果を確認するには（次のセクションを参照してください、ツールの利用にポストマン）ポストマンに合格
def post(self,request):
print(request.data) #打印结果是：{'name': 'chao'}
return HttpResponse('POST')
私たちはこれらの変数は、我々は内部クラスのコンポーネントを表示するさまざまなクラスを制御するために使用され、クラス変数を追加するために私たちのクラスにしようとした、第一：私たちは、上の読み
コードを見てください：
from django.shortcuts import render,HttpResponse,redirect
import json
from django.views import View
from app01 import models
from rest_framework.views import APIView
#导入解析器
from rest_framework.parsers import JSONParser,FormParser,MulTiPartParser
# JSONParser:解析json数据的额
# FormParser：解析urlencoded数据的
# FileUploadParser：解析文件数据的
class CourseView(APIView):
#写一个类属性，名字必须是parser_classes
parser_classes = [JSONParser,] #里面存放我们上面导入的那几个解析器,如果我们里面写了一个JSONParser，那么解析器只能解析前端发送过来的json数据，存放到request.data里面，可以通过postman测试一下看看效果，为什么？看源码吧
def get(self,request):
course_obj_list = models.Course.objects.all()
ret = []
for course_obj in course_obj_list:
ret.append({
"title":course_obj.title,
"desc":course_obj.desc,
})
return HttpResponse(json.dumps(ret, ensure_ascii=False))
def post(self,request): print('ok') #你会发现，即便是发送的数据类型不对，post方法也走了，但是request.data没有东西，那么肯定是它出了问题
print(request.data) #request.data对我们的数据进行解析的，那么说明data不是一个变量，而是一个属性方法，还记得属性方法吗
return HttpResponse('POST')
ソースはより複雑に見えた、私はそれらを表示されません、とにかくあなたが知りたい、私たちのパーサを使用するためのための外観はです。
[JSONParser、] parser_classes =内部で独自のクラスを書く---->その後、----->で設定を見つけ、その後ちょうどそれが使わ見つけ、デフォルトを見つけます。我々は他を読んでいないので、他の成分には、また、このようなシーケンスです。
四ポストマンの使用
ポストマンは、このツールなしで、リクエストを送信し、応答結果を取得するためのシミュレーションツールで、我々はと、それはすべてのブラウザを介してアクセスするプロジェクトを、開始していないときにWebプロジェクト、デバッグ・インタフェース・リターン・データを書き込み、その後、データのああを見ます私たちは、ブラウザを起動することはできません。この手段は、このツール、最初のダウンロードを介してデバッグすることが可能とインストールされます
ダウンロード：https://www.getpostman.com/downloads/
インストールと使用、ダイレクトプラグインには、1を理解することができます：
