DRF--はじめとインストール

前端と後端を分離していません

以前のアプリケーションモードの後端から分離されていない、効果のフロントページは、後端部による表示の後端部の前端部を制御すること、すなわち、後端又はリダイレクトページレンダリング、前端と後端との結合の高度に制御され、参照します。このアプリケーションモードでは、純粋なWebアプリケーションのために適しているが、バックエンドのWebインタフェースが復帰しなければならなかったので、バックエンドドッキングアプリケーション、アプリケーションは、バックエンドは、HTMLページを返す必要が、唯一のデータそのものではないかもしれとき、フロントエンドアプリケーションのAppには適用されません。尻アプ​​リケーションのバックエンドにするためにも、インタフェースのセットを開発する必要があります。

 

別々の前端と後端

以前のアプリケーションモード、のみリターンの前端部の後端に必要なデータと、もはやレンダリングHTMLページ、フロントエンドの無制御効果の後端部を分離します。フロントエンドで自分自身をどのように決定するか、負荷へのフロントエンドにどのような影響を与えるバックエンドから要求されたデータを、参照するには、フロントエンドのユーザー、Webページのための治療法があるので、治療が、いずれかのフロントエンドのアプリケーションのApp、必要なデータがあります基本的に同じ、唯一のバックエンド・ロジックを開発するためには、外部データを提供することができます。

以前のアプリケーションモードの後端部を分離し、我々は、通常、各ビュー用に開発されたデータを変更して再検索を削除するフロントエンド・インタフェースを介してアクセス、インタフェースの後端部、またはAPIと呼ばれています。APIは、様々なスタイルを持っていますが、今より多くの主流とここで有用なRESTfulなAPIを言うことです。

RESTfulな

RESTfulなは、ソフトウェアアーキテクチャのスタイル、デザイン、というよりも標準ですが、設計原理と制約のセットを提供します。これは主に、クライアントとサーバの対話クラスのソフトウェアのために使用されています。ソフトウェアのこのスタイルに基づいて、より簡潔、より構造化およびキャッシュ機構を実装しやすくすることができます。

RESTは、中国は、状態遷移を特徴づけるためのもの、のRepresentational State Transferの略。それは2000年に初めて登場し、ロイ・フィールディングの博士論文、ロイ・フィールディングは、HTTP仕様の主な著者の一人です。彼は論文で述べた：「私はこの記事を書くの目的は、通信に適した、アーキテクチャ設計は、強力な機能を取得し、良好な性能をWebベースのアプリケーション・ソフトウェアを理解し、評価するために、アーキテクチャの原則に準拠して、にありますアーキテクチャ.RESTは、建築制約と原則のセットを指す。「RESTの制約と一致枠組みと原則は、我々はRESTfulなアーキテクチャを呼び出した場合。

アイデアの背後に隠れが良く、RESTfulなWebの既存の機能と能力を使用するWeb標準を既存のいくつかのガイドラインと制約を使用している間REST自体は、新しい技術、コンポーネントやサービスを作成しません。深くREST Web技術自体の影響を受けますが、しかし、理論的にはRESTアーキテクチャ・スタイルは、HTTPにバインドされたが、現在唯一のHTTP REST関連のインスタンスされていません。

RESTfulなコア事業：URLは、操作のHTTP動詞（GET、POST、DELETE、DETC）の説明とリソースを探します。

何が良いことがあることをこのスタイルのインターフェイス？前後端を分離することができます。フロントエンドは、表示とレンダリングのための唯一の責任のデータを取得し、かつ任意のデータ処理を行いません。バックエンド処理とJSON形式アウト送信データは、均一なインターフェース、ウェブは、IOSは、同じインターフェースを使用することができる3つの端子をアンドロイドように定義されます。

RESTfulな練習

• APIおよびユーザの通信プロトコル、可能な限りHTTPSプロトコルを使用して。
• ドメイン名
  • https://api.example.comこれを使用しないことをお勧め（クロスドメインの問題があるでしょう）
  • https://example.org/api/ APIは非常に簡単です
• 版
  • します。https：//api.example.com/v1/のようなURL、
  • これは、リクエストヘッダに含まれます
• URL、すべてのものは資源、両方の使用の名詞の意味（複数でも可）であります
  • https://api.example.com/v1/zoos
  • https://api.example.com/v1/animals
  • https://api.example.com/v1/employees
• 方法
  • GET：サーバーからリソース（一つ以上）を削除
  • POST：サーバ上に新しいリソースを作成します。
  • PUT：アップデートサーバのリソース（変更後にクライアントが提供する完全なリソース）、完全更新
  • PATCH：サーバ内の（プロパティを変更するには、クライアントによって提供された）更新されたリソース、地元のアップデートは、サポートされていない可能性
  • DELETE：サーバーからリソースを削除
• フォームのURLにアップロードされた検索条件パラメータを通過させ、ろ過し、
  • https://api.example.com/v1/zoos?limit=10：指定したレコードの数が返されます
  • https://api.example.com/v1/zoos?o?set=10：指定されたレコードの開始位置を返します。
  • https://api.example.com/v1/zoos?page=2&per_page=100：指定最初の数ページだけでなく、ページあたりのレコード数
  • https://api.example.com/v1/zoos?sortby=name&order=asc：結果は属性によってソート返し指定、およびソート順
  • フィルタ条件を指定します。https://api.example.com/v1/zoos?animal_type_id=1
• +コードステータスコード情報
  • 　
• エラー処理、ステータスコードの4xx、エラーメッセージが返されます。
  • 　

• 異なる操作の戻り結果は、結果は以下の仕様を満たす必要があり、ユーザーにサーバーから返されました
  • 

詳細なHTTPリクエストメソッド

要求：クライアントとして指定されたリソース/サーバ上で動作させるために何を望んで指定します

標準のHTTP、HTTPリクエストには、いくつかのリクエストメソッドを使用することができます。

GET、POST、およびHEADメソッド：HTTP1.0の要求は、3つのメソッドを定義します。

HTTP1.1 5つの新しい要求方法：OPTIONS、PUT、DELETE、TRACE、およびCONNECTメソッド。

 

 

• GET：リソースへのアクセスを

GETメソッドは、要求リソースに使用されているURIを特定されています。リソースは、サーバ復帰によって応答解析されたコンテンツ指定（要求されたリソースがテキストである場合、すなわち、それはリターンとして残ると、もしCGI [共通ゲートウェイインターフェイス]手順として、戻りの出力後に行われます） 。最も一般的にサーバに特定の情報を照会するために使用。必要な場合は、サーバーに情報を送信するためには、URLの末尾にクエリ文字列パラメータを追加することができます。

• POST：トランスポートエンティティのテキスト

エンティティボディを送信するためのPOSTメソッド。GETメソッドは、メインエンティティによって送信することができるが、一般なくPOSTメソッドで送信する方法を得ることはありませんが、GETおよびPOSTメソッド、非常に類似しているが、しかし主な目的は、応答のPOSTボディコンテンツを取得することはありません。POSTリクエストのボディは、多くのデータを含んでいてもよいが、フォーマットが限定されるものではありません。

• 根本的に異なる方法では、メソッドをGETとPOST：

図1に示すように、情報を取得するためのGETメソッドは、それが安全である（安全は：そのような情報のデータベースとして、非修飾情報を参照）、およびPOSTメソッドは、サーバのリソースを変更する要求です。

2、GET请求的数据会附在URL之后，而POST方法提交的数据则放置在HTTP报文实体的主体里，所以POST方法的安全性比GET方法要高；

3、GET方法传输的数据量一般限制在2KB，其原因在于：GET是通过URL提交数据，而URL本身对于数据没有限制，但是不同的浏览器对于URL是有限制的，比如IE浏览器对于URL的限制为2KB，而Chrome，FireFox浏览器理论上对于URL是没有限制的，它真正的限制取决于操作系统本身；POST方法对于数据大小是无限制的，真正影响到数据大小的是服务器处理程序的能力。

• HEAD：获得报文首部

HEAD方法和GET方法一样，只是不返回报文的主体部分，用于确认URI的有效性及资源更新的日期时间等。 具体来说：1、判断类型； 2、查看响应中的状态码，看对象是否存在（响应：请求执行成功了，但无数据返回）； 3、测试资源是否被修改过 HEAD方法和GET方法的区别：GET方法有实体，HEAD方法无实体。

• PUT：传输文件

PUT方法用来传输文件，就像FTP协议的文件上传一样，要求在请求报文的主体中包含文件内容，然后保存在请求URI指定的位置。但是HTTP/1.1的PUT方法自身不带验证机制，任何人都可以上传文件，存在安全问题，故一般不用。

• POST和PUT的区别

POST 方法用来传输实体的主体，PUT方法用来传输文件，自身不带验证机制。这两个方法看起来都是讲一个资源附加到服务器端的请求，但其实是不一样的。一些狭窄的意见认为，POST方法用来创建资源，而PUT方法则用来更新资源。这个说法本身没有问题，但是并没有从根本上解释了二者的区别。事实上，它们最根本的区别就是：POST方法不是幂等的，而PUT方法则有幂等性。那这又衍生出一个问题，什么是幂等？

幂等（idempotent、idempotence）是一个抽象代数的概念。在计算机中，可以这么理解，一个幂等操作的特点就是其任意多次执行所产生的影响均与依次一次执行的影响相同。POST在请求的时候，服务器会每次都创建一个文件，但是在PUT方法的时候只是简单地更新，而不是去重新创建。因此PUT是幂等的。

• DELETE：删除资源

指明客户端想让服务器删除某个资源，与PUT方法相反，按URI删除指定资源OPTIONS：询问支持的方法OPTIONS方法用来查询针对请求URI指定资源支持的方法（客户端询问服务器可以提交哪些请求方法）

• TRACE：追踪路径

客户端可以对请求消息的传输路径进行追踪，TRACE方法是让Web服务器端将之前的请求通信还给客户端的方法

• CONNECT：要求用隧道协议连接代理

CONNECT方法要求在与代理服务器通信时建立隧道，实现用隧道协议进行TCP通信。主要使用SSL（安全套接层）和TLS（传输层安全）协议把通信内容加密后经网络隧道传输。

DRF

官网地址：https://www.django-rest-framework.org/

Django Rest Framework是一个强大且灵活的工具包，主要用以构建RESTful风格的Web API。Django REST Framework（以后简称DRF）可以在Django的基础上迅速实现API，并且自身还带有基于WEB的测试和浏览页面，可以方便的测试自己的API。DRF几乎是Django生态中进行前后端分离开发的默认库。

Django REST Framework具有以下功能和特性：

• 自带基于Web的可浏览的API，对于开发者非常有帮助
• 支持OAuth1a 和OAuth2认证策略
• 支持ORM或非ORM数据源的序列化
• 高可自定制性，多种视图类型可选
• 自动生成符合 RESTful 规范的 API
• 支持 OPTION、HEAD、POST、GET、PATCH、PUT、DELETE等HTTP方法
• 根据 Content-Type 来动态的返回数据类型（如HTML、json）
• 细粒度的权限管理（可到对象级别）
• 丰富的文档和强大的社区支持
• Mozilla、Red Hat、 Heroku和Eventbrite等知名公司正在使用

安装：

pip install djangorestframework
pip install markdown    # Markdown
pip install django-filter  # 可选
pip install coreapi      # 可选

coreapi（1.32.0+） - 支持模式生成和coreapi命令行工具。

Markdown（2.1.0+） - 可浏览API的Markdown支持。

django-filter（1.0.1+） - 过滤支持。

django-crispy-forms - 改进的HTML显示过滤。

django-guardian（1.1.1+） - 对象级别的权限支持

安装完毕，在项目配置文件中，注册app：

INSTALLED_APPS = (
 ...
 'rest_framework',
)