ExtJSバックエンドのクイックスタート

問題を理解する

状況を想像してみてください：あなたはフリーランサーであり、Extで働いています。 1人（または複数人）のバックエンド開発者がリモートで作業します。 作業は高速でスムーズです。 しかし、サーバー側の開発者が変わったのは偶然です。 新しい同僚がExtの経験がある場合は、すべて順調です。 しかし、ある人が最初にExtのバックエンドを書いたり、初めてWebのことを書いた場合（これも起こります）、共通言語を見つける必要があります。

そして、ここで問題が始まるかもしれません...

プロトコルの簡単な説明に時間を費やす必要があり、サーバーが特定のリクエストにどのように応答するかを説明します。 これを避けるために、私はすべて（まあ、またはExtの標準プロトコルのほとんどすべてのニュアンス）を説明するドキュメントを準備しました。 このドキュメントは、カットの下に表示されます。

理解の問題の解決策

ExtJsはREST相互運用性アーキテクチャを最大限に活用します。 それは何であり、彼らが食べるものはすでにハブに書いています：

REST対SOAP。 パート1.違いを感じる

Webサービスのタオ。 （または、自転車の発明をやめてください！）

最初のトピック（ Artiom1988 ）の著者-テーブルに多くの人間のおかげで、開発者とのコミュニケーションに多大な時間を節約できました。 そして、私は（小さな変更を加えて）文書を盗みました

標準のHTTP操作

URL	ゲット	投稿	置く	削除
example.com/ticket	すべてのチケットのリストを取得する	新しいチケットを作成する	チケットのリストを更新する	すべてのチケットを削除します
example.com/ticket/15（15はチケットIDです）	特定のチケットに関する情報を取得する	-	チケットを変更します	特定のチケットを削除する

URLに最後のスラッシュ（www.exam.com/ticket/）が含まれている場合、およびスラッシュが欠落している場合（www.exam.com/ticket）にリクエストが機能するはずです。



各オブジェクト（チケット、ユーザーなど）には、idフィールド（整数値の形式の一意の識別子）があります。

メッセージフォーマット

すべてのメッセージは有効なJSONで送信されます。

次に、次の形式の配列構成を呼び出します。

[1,2,3,4,"",true, false, "34"]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

建設の目的は

 {"param1" : "value1", "param2" : true, "param3": 45}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

パラメータ名は常に文字列（二重引用符）であり、パラメータ値は文字列、数値、ブール値（trueおよびfalse）であることに注意してください

フィールドはパラメーター名と呼ばれ、上記のオブジェクトにはフィールドparam1とparam2があります



オブジェクトには、配列、および配列オブジェクトを含めることができます。たとえば、

 { "success": true, "items" : [ { "name": "Vasya" }, { "name" : "Sveta" }] }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

クライアントリクエストフォーマット

POSTおよびPUT

オブジェクトである1つのアイテムパラメーターが含まれています

 {"name":"123","id":0,"region_id":2,"region_name":""}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ゲット

リストをリクエストするとき、標準パラメータを含めることができます：

start-応答が始まるレコード番号

limit-返されるレコードの最大数

filter-フォームのオブジェクトを含む配列

 {"property":"name","value":""}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

つまり GETリクエスト

/users?start=40&limit=20&filter=[{"property":"name","value":""}]





（リクエストは当然uriエンコードされます）データベースから最初の40人をスキップして、Vasyaという名前の20人のユーザーを返す必要があります。

検索フィールド+文字列 "_like"のような名前のフルネームフィルタリングでフィルターを使用することをお勧めします。 つまり フィルター

 {"property":"name_like","value":""}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

VasilievとVasilisの両方が見つかります。 全文検索のパラメータは、当然指定する価値があります。

サーバー応答フォーマット

答えは常にオブジェクトです。

ブール値を取ることができる成功フィールドが必要です。

GETリクエストへの応答

アイテムのリストが要求される場合、応答には合計フィールドが必要です。これは、このコントローラーのデータベース内の行の合計数を示す整数です（つまり、 フィルターと制限パラメーターを指定し、いくつかのレコードを取得した場合、とにかく合計エントリの数を示します）。

特定のアイテムがリクエストされた場合（ exmple.org/users/5



exmple.org/users/5



）、 合計フィールドは設定されていません。



データ自体は、 項目オブジェクトにあります。これは、データオブジェクトを含む配列です。

 { "items":[{ "region_id":2, "name":"Moscow", "id":25 },{ "region_id":1, "name":"Piter", "id":18 }], "success":true, "total":2 }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

1つのオブジェクトが要求された場合、配列は使用されません

 { "items":{ "region_id":2, "name":"Moscow", "id":25 },{ "region_id":1, "name":"Piter", "id":18 }, "success":true }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

DELETEクエリへの応答

 {"success":true}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

-それで十分です

POSTおよびPUT要求への応答

GETリクエストへの応答と同様に、特定のオブジェクトをリクエストする場合、既に変更されたデータのみを返す必要があります。

間違い

エラーの場合、 成功フィールドはfalseで、エラーフィールドも追加されます-エラーの説明を含む行の配列

 {"errors":["Object not found"],"success":false}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

データの命名

オブジェクトが別のオブジェクトを参照する必要がある場合、 _idプレフィックスを持つパラメーターが使用されます 。 サーバーがオブジェクト都市を返し、都市が地域にある場合、答えは次の形式になります。

 {"region_id":2,"name":"Moscow","id":25}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

必要に応じて、地域の名前を含むregion_nameフィールドを追加できます（また、cityテーブルにキャッシュされるフィールドとしてデータベースで機能します）。



1つのオブジェクトに多くが含まれ、ネストされた階層を取得する必要がある場合、複数形の名前を持つ配列フィールドが使用されます。 複数の都市が接続されている地域をリクエストする場合、答えは次のようになります。

 { "id":2, "name":"Central", "cities" : [{ "name": "Moscow", "id":2 },{ "name":"New York", "id":3 }] }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

バックエンドのテスト方法

テストにはすばらしいGoogle Chrome拡張機能を使用できます。

1. GETリクエストの送信（サーバー上のデータベースには少なくとも1つのアイテムが必要です）
2. すべてまたは必要なデータを含むPOST要求を送信します。 応答には、新しいトピックに関する情報が含まれている必要があります。
3. GETリクエストを送信し、段落2で作成されたアイテムの存在を確認する
4. 条項2で作成され、条項3のリストに含まれるアイテムを変更するためのPUT要求を送信する。応答には、変更されたアイテムに関する情報が含まれている
5. GETリクエストを送信し、パラグラフ4で作成されたアイテムへの変更を確認する
6. DELETE要求を送信して、ステップ2で作成されたアイテムを削除します。確認メッセージが返されます。
7. GETリクエストを送信し、パラグラフ2で作成されたアイテムが存在しないことを確認する

おわりに

おそらく、このドキュメントはだれにとっても役に立たず、私のような誰かが少し貴重な時間を節約するでしょう。