REST APIを実装するためのJSON形式でのオブジェクトのシリアル化

Symfony 2.1がリリースされようとしており、コミュニティはまだ松葉杖なしで本格的なRESTを実装することはできません。私の意見では、ここで何かが間違っています。 最近、 Symfony2でREST APIの大声でタイトルを付けて記事が公開されました：正しい方法ですが、本質的には、私の言葉を確認するだけです。 全体の問題は、オブジェクトのシリアル化と逆シリアル化にあります。 最も単純なタスクとソリューションは多くあるはずですが、残念ながら、そうではありません。 順番にすべてについて話しましょう。



JMSSerializerBundleは、おそらく、現時点でのシリアル化のトレンドセッターです（FOSRestBundleでも宣伝されています）。 多機能であり、さまざまな形式でシリアル化ルールを保存し、さまざまな形式でデータをシリアル化および逆シリアル化し、キャッシュを使用できます。 しかし、彼にはいくつかの小さな未解決の問題があり、それらは何度も触れられており、それらの解決策は期待されていません。 多機能性を追求する中で、アプリケーションアーキテクチャが停止したように思えます。



最初の問題は、それぞれ多くの依存関係を引き出すバンドルです。これはSymfony 2の外部では使用できません。これは非常に奇妙です。なぜなら、質問はもともとシリアル化に関するものであり、ライブラリにしない理由は明らかではないからです。



2番目の問題は、null値をシリアル化できないことです。 REST APIに関連して-これは受け入れられません。 非常に大きな問題がありますが、解決策はないと確信しています。 実際、状況は非常に奇妙です。 json_decodeとjson_encodeを使用すると、このタスクを正しく処理します。 xml形式については、1年前にdoctrine-oxmを実装するときにこの問題を解決しました 。



3番目の問題は、既存のデータオブジェクトに逆シリアル化できないことです。 これにより、部分的なデータ更新を実行するPOST / PATCH要求を使用できなくなります。 主な質問は、Symfony 2でのRESTの簡単な実装について、FOSRestBundleがいかに人々をだましてきたかです。



長い間、誰もSymfony2でRESTの本格的な実装を行ったことがなく、これらの問題に遭遇していなかったとは信じられませんでした。 私たちは多くの決定に目を通し、不死のチェが歌ったように、「すべてが正しくなく、すべてが間違っている」と歌いました。 ある晴れた日、 Benjamin Eberleiに満足しました。BenjaminEberleiは 、独自のバンドルSimpleThingsFormSerializerBundleを作成することで3番目の問題に注目しました。 しかし、残念ながら、他のSymfony2コミュニティと同様に、バージョン2.1には「取りつかれ」、ベータ版さえもありませんでした。 しかし、これは別の話であり、幸いなことに、2.0と互換性のある人がいました。



だから、幸福はすでに近いようで、モデルを更新することができます。 どんなに困難であっても、DTO（データ転送オブジェクト）オブジェクトのFormTypeを作成し、JMSSerializerBundleをSimpleThingsFormSerializerBundleに完全に置き換えます。 彼らはそれをしましたが、彼らは幸せを見つけませんでした。 結局のところ、新しいバンドルはすべての情報を文字列に変換します。 クライアントは数値やブール値を決して見ることはありません。 なぜこれが行われたのかという質問に対する回答は得られませんでした。JMSSerializerを使用して、逆シリアル化するためのシリアル化-FormSerializerの提案しかありませんでした。 しかし、ここで何かが間違っているように思えます。 さらに、バージョン2.0のsymfonyフォームは、GETまたはPOSTリクエストでのみバインドを生成でき、残りは無視します。 はい、RESTのフォームの使用に関して多くの "fi"がありますが、これは記事の範囲外です。 何かが変わることを期待して、2週間休暇をとりました。 しかし...



タスクは単純に思えますが、REST APIでは、json形式で情報を提供することが保証されています。 他の形式は私たちの興味を引くものではありません（私には、最新のプロジェクトのように）。 属性のメソッドを常に設定/取得するDTOオブジェクトがあると仮定します。 これらのDTOをjsonに変換したり、逆に変換したりします（上記の問題の解決方法を使用）。 シリアル化ルールをyml形式で保存し、JMSSerializerBundleのさまざまな設定をすべて保存する機能が本当に気に入っています。フィールドのマッピング（「serialized_name」と「type」）とフラグ「expose」のみを指定する必要があります。



ライブラリの実装を進める前に、現在のソリューションをもう一度検索しました。 2つの興味深いプロジェクトが見つかりました。

FbsSerializer-どうやら 、JMSSerializerBundleの「前身」です。 実装の可能性とアイデアは非常に似ており、同じ問題が存在し、コレクションを不適切にシリアル化します。

ObjectSerializerは非常に単純な実装であり、ライブラリを見る方法とほぼ一致しました。 主な欠点は、クラスマッピングがコンストラクターを介して渡されることです。これは受け入れられません。



最近、実装が簡単になりました。 コードが単純であるほど、責任が少なくなります-より良い。 誰も必要としない機能を含むコードを記述したくはありません。アプリケーションアーキテクチャが故障します。

<?php class Serializer { public function serialize($object) { $array = $this->arrayAdapter->toArray($object); return $this->adapter->serialize($array); } public function unserialize($data, $object) { $array = $this->serializerAdapter->unserialize($data); return $this->arrayAdapter->toObject($array, $object); } } ?>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

基本的な考え方は、さまざまなシリアル化ルールを持つ複雑なオブジェクトを配列に変換することです。 これはArrayAdapterによって行われ、データ変換のロジック全体をカプセル化します。 生成された配列は簡単にjson形式に変換されます。xmlに問題はないと思います。 逆シリアル化の間、逆のことが当てはまります。入力データを配列に変換し、ArrayAdapterが独自のルールに従ってデータをオブジェクトに変換します。



この場合、serializerAdapterは、json_encode、json_decode関数の単純なラッパーを表します。 興味のあるロジックはすべてArrayAdapterにあります。 ここで、構成データの処理と、このライブラリとFbsSerializer、JMSSerializerBundleのシリアル化のイデオロギーの違いを見つけます。



私の見解では、いくつかのスペースのいくつかのファイルにあるオブジェクトをシリアル化するための一連のルールがあります。 まず、このスペースから構成を取得する必要があります。 しかし、構成が保存される多くの形式が存在する可能性があり、使いやすさのためにこれをオブジェクト表現に変換することは論理的です。 Johannes Schmittは、 メタデータライブラリを使用してこれを行います。 これは非常に優れていますが、オブジェクトの反射に密接に関連しています。 したがって、後で、シリアル化中に、すべての作業はシリアル化可能なオブジェクトとそのReflectionから行われます。 簡単に言うと、オブジェクトで可能なすべての項目を反復処理し、この属性またはメソッドの設定を確認します。 このアプローチは、値の複雑な処理（より簡単にできる）と組み合わせることで、未解決の問題の原因の1つであると考えています。 そして、私の実装では、反対のことを行います。 構成を、シリアル化可能なオブジェクトについて何も知らないオブジェクト表現に変換するだけです。 次に、メタデータを反復処理し、現在の属性、そのタイプ、およびその処理方法をシリアル化できる名前でシリアル化できるかどうかを確認します。 データ処理の過程で、必要なゲッター/セッターを呼び出します。 したがって、オブジェクトからではなく、指定された構成から進みます。 彼らが言うように、彼らは尋ねた-彼らはそれを得た。 以下はコードのスニペットです。

 <?php class ArrayAdapter { public function toArray($object) { $result = array(); $className = $this->getFullClassName($object); $metadata = $this->metadataFactory->getMetadataForClass($className); foreach ($metadata->getProperties() as $property) { //handle value $result[$property->getSerializedName()] = $value; } return $result; } public function toObject(array $data, $object) { $className = $this->getFullClassName($object); $metadata = $this->metadataFactory->getMetadataForClass($className); foreach ($metadata->getProperties() as $property) { //handle value and set it to object } return $object; } } ?>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

シリアル化/逆シリアル化の値を処理するために、現在、プライベートhandleValueメソッド（約60行）を使用しています。



最初は、設定をymlファイルからオブジェクトに変換するために、タスクが非常に単純なので、自分で何かを書きたいと思いました。 構成ファイルの場所（ファイルシステム、メモリ、データベースなど、どこにでも保存できます）とその形式（yml、json、ini、xml）の2つから抽象化する必要があります。 同時に、チームリーダーが「毎回* .ymlファイルを解析するわけではない」と述べたように、キャッシュが必要です。 そのインターフェースは、put、get、removeのすべてに知られています。 しかし、私は時間内に停止し、メタデータライブラリを思い出し、再び不要なReflectionに遭遇しました。 したがって、マイナーな修正を加えて、コードのこの部分はそこから引用され、ヨハネスに敬意を表しています。



その結果、チームのために33時間失われましたが、 simple-serializerライブラリとOpensoftSimpleSerializerBundleバンドルが作成されました 。



ライブラリの依存関係：

symfony / yamlコンポーネント



要件：

-直列化可能なオブジェクトの場合、直列化規則を記述する必要があります。

-シリアル化可能なオブジェクトには、属性のセッターとゲッターが必要です。



JMSSerializerBundleと比較した利点：

-次のような多くの問題はありません。null値を持つ属性の処理、既存のオブジェクトへのデータの逆シリアル化。

-構成での日付の書式設定。

-symfony 2フレームワークへのバインディングはありません。



当然、これは理想的ではありません。 JMSSerializerBundleはより機能的であり、制限が少なくなっています。 しかし、私たちの場合、REST APIの実装での使用には明らかなバイアスがあります。 大規模なアプリケーションでRESTを扱う場合、モデルがAPIに明示的に反映されることはないため、 DTOパターンを実装せずに行うことはできません。 また、それに応じて、DTOをDomainObjectに変換するときに、アセンブラーはセッター/ゲッターメソッドを使用する可能性が高くなります。 そして、2番目の要件は自動的に消えます。 最初は、すべてを行うと思います。 結局のところ、APIを顧客に提供することにより、私たちはどのような形式で、私たちが受け入れるか与えるかを伝えます。 そして、これらのルールがなければ、それは非論理的なようです。 さまざまな形式の応答については、プロジェクトでjsonを扱っています。 非常にシンプルで便利です。 私の意見では、XMLはRESTで使用するにはすでに少し時代遅れです。 FOSRestBundleが提供するHTML形式はあまりにも手に負えないので、その使用は想像できません。 動作テストはREST APIの信頼性に責任があります（こんにちは、Konstantin別名everzetに感謝します ）。 コードセプションは本当にクールなので、 davertが気分を害さないことを願っています。



シリアル化を構成する可能性について個別に話す価値があります。 オプションは最小限に抑えられていますが、補完することはまったく難しくありません。 構成ファイルは通常、JMSSerializerBundleに似ています。

 MyBundle\Model\Order properties: id: expose: true serialized_name: id type: integer
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

「expose」オプションのデフォルトは「false」です。したがって、シリアル化するすべての属性について、指定する必要があります。 これは私の個人的な好みであり、許可されていないものは禁止されています。 おそらく、若者のACLの影響でしょう。 原則として、必要に応じて本格的な除外/公開を実装できます。 Serialized_nameはオプションのパラメーターであり、指定されていない場合、属性は名前に従ってシリアル化されます。 最後の「タイプ」オプションもオプションです。 指定されていない場合、属性値を持つアクションは実行されません。 それ以外の場合は、指定された型にキャストされます。 可能なタイプ：整数、ブール、ダブル、文字列、配列、T、配列<T>、DateTime、DateTime <format>。

JMSSerializerBundleとの主な違いは、ArrayCollectionが存在しないことと、DateTime <format>が存在することです。 前者は基本的に存在しません。なぜなら、その存在はDoctrine / Ormへのライブラリ依存を追加するからです。 symfony 2フレームワークを使用する場合、90％で満足します。 しかし、他の10パーセント、またはsymfonyを使用しない人はどうでしょうか？ さらに、DTOへの適用について話している場合、ほとんど確実にコレクションはありません。意味がありません。 しかし、この問題は将来解決される可能性があります。 2番目の機能は、日付のフォーマット方法を指定する機能です。 DateTimeエントリは、DateTimeオブジェクトがあると想定していることを思い出してください。 間違っていなければ、JMSSerializerBundleでカスタム日付ハンドラーを作成し、その形式を指定できます。 ここではすべてがより簡単です。構成で直接、DateTimeクラスの定数（たとえば、「ISO8601」）、または必要な時刻形式の文字列を指定できます。



TODOリストを作成できますが、正直なところ、私はこれを緊急の必要性とは思いません。

1）シリアル化構成を他の形式（注釈、xml）で保存する機能を追加します。

2）JSON以外の形式にデータをシリアル化する機能を追加します。

3）構成にさまざまなオプションを追加します。

4）handleValueのコードをリファクタリングし、Visitor、Chain of Responsobility、または他の何かを実装して、カスタム値ハンドラーを作成する機能を追加します。

5）他の何か。



謝辞：私は特に、チームリーダーに「それを乗り越える」ことを許可してくれたこと、プロジェクトのリリース前の困難な時間、そして私が至福の間にバグを破壊したチームに忍耐してくれたことに感謝します。 ベンジャミンのヨハネスに感謝します-あなたは本当にクールな人であり、私たちは車輪を再発明するのは好きではありませんが、私たちには選択肢がありませんでした。