1

アプリケーションのCRUD「レイヤー」を作成しています。これは単純な CRUD アプリケーションで、たとえば、ユーザー情報やお気に入りリンクなどを保存し、「ファクト タイプ」データを操作しません。実際には、アプリケーションの他の部分が作業を実行するために取得するユーザー、アクセス許可、ルール、ポリシーなどを保存するだけです。

全体として、私はこの取り組みから 3 つのことを望んでいます。

  • (a) CRUD 機能にアクセスするための単一のエントリ ポイント
  • (b) CRUD 層を使用するために任意の「クライアント」を使用する機能
  • (c) CRUD の「簡単な」拡張性。新しいオブジェクトを追加したり、古いオブジェクトを変更したりできます (新しいフィールドが追加され、他に何も削除または変更されていません)。典型的な CRUD シナリオ?

Java ライブラリを作成し、HTTP 経由で「REST-type-URL」( 「users/delete/2」のような REST-URL 方式を意味する) API を介してクライアントに公開する必要があると考えています。このようにして、3 つの目標すべてを達成できます。CRUD レイヤーは Linux に配置でき、クライアントは Windows に配置できます。

CRUD レイヤーでは、ORM、Web サーバー、その他のツールなど、さまざまなものを使用してこれを実現します。

それは正しい方法のように思えますが、このアプローチは理想主義的すぎて、実装を開始すると機能しない可能性があるのではないかと考えずにはいられません。

私が考えているのは、一連の API メソッドを XML フラグメントに詰め込むという、過度に単純化した見方ですか? (私は XML-RPC を行っていないことに注意してください。むしろ、これらの XML フラグメントはデータのみになります。XML は users/update/2 などの特定の URL に送信され、XML に含まれていることを確認した後に XML を処理します。ユーザー プロファイルの情報)

私の考えは正しいですか？このアイデアが機能する可能性はほとんどありませんか?

どんな助けでも大歓迎です！

4

4 に答える 4

2

はい、動作します。ただし、分散システムの設計は、データ モデルが非常に単純であり、そのまま維持されるという前提に基づいています。構築しているアプリケーションが成功した場合、新しい要件が追加され、新しい機能が要求されることは確実です。

あなたが提案しているようにデータレイヤーを公開すると、クライアントアプリケーションがデータモデルに緊密に結合され、httpを使用するとマルチリクエストトランザクションが非常に困難になります。マルチリクエストトランザクションを行う必要はないと言っていました。今日じゃなくて来年かな？

このアプリケーションの寿命はどれくらいですか? 数年以上という場合は、データ層をリモート クライアントに公開するという考えを再考します。REST の主な目標の 1 つは、クライアント アプリケーションとサーバー アプリケーションを分離して、アプリケーションが長期間にわたって進化できるようにすることです。適切に設計されていない分散サービスに複数のクライアント アプリケーションがアクセスしている場合、メンテナンスやバージョン管理の問題がすぐに発生する可能性があります。

クライアントがモデルを理解する必要があるというコメントの質問に答えるために編集します。

クライアントがサーバーから受信した表現と対話する方法に関して、2 つの異なる方向性があります。

  1. クライアントが、表現に含まれるデータ コンテンツを明示的に認識できるようにすることができます。つまり、クライアントは特定の XML 要素にユーザー名とパスワードがあることを知っています。ただし、これを行う場合は、特定のメディア タイプ (application/vnd.mycompany.user+xml など) を返す必要があります。application/xml を使用しないでください。これは、XML ドキュメントの内容についてクライアントに何も伝えないためです。クライアントが「URL X に移動すると」「要素 User 内に要素 UserName と Password を含む Xml ドキュメント」を取得するという知識を持っている場合、REST の自己記述的制約に違反しています。影響は、エンドポイントをメディア タイプに結合し、事実上クライアントをそのエンドポイントに結合したことです。「ハイパーメディア制約」の意図
  2. 別の方法は、より一般的なメディア タイプを使用することです。このメディア タイプは、単にクライアントにコンテンツを提供してユーザーに表示し、クライアントがアクションを実行できるようにするためのオプションをユーザーに提供することを目的としています。html メディア タイプを使用すると、2 つの div タグでユーザー名とパスワードを返すために使用できるマークアップ言語を提供することで、これを行うことができます。html FORM タグと A タグを使用して、クライアントはそのリソースに対して追加の操作を実行できます。「ユーザー」オブジェクトが持つ可能性のあるすべての操作に、真の RESTful な方法でアクセスできるようにする方法を理解するのは難しく、かなりの経験が必要ですが、最終的にはクライアントとサーバーが非常にうまく分離されます。例として Web ブラウザーを見てください。Web サイトのコンテンツが変更されたために、ブラウザーの更新を行う必要がある頻度はどれくらいですか。

オプション 2 の問題点は、HTML だけを使用するとエンドユーザー エクスペリエンスがかなり制限される傾向にあり、そこで Javascript の出番です。「オプションの」REST 制限の 1 つは、コード ダウンロードの使用です。Javascript は、クライアントで追加の動作を有効にするためにサーバーからロードされるコードです。残念ながら、私の意見では、アプリケーション/xml を返す RESTful Web インターフェイスを作成し、javascript を使用してその一般的な形式を解釈する機能も提供します。このソリューションは、RESTful API を使用する Web サイトの元の開発者にとっては問題なく機能します。xml ファイルのコンテンツが変更された場合、javascript を変更してブラウザーに再ダウンロードすれば問題ないからです。でも、アプリケーション/xml コンテンツ モデルを制御できない、この API にアクセスしている他のサード パーティ開発者の場合、コードは完全に脆くなり、API コンテンツが変更されると破損する可能性があります。何らかの種類の Twitter クライアントを作成したことがある人に尋ねてください。Twitter がコンテンツを変更したためにアプリケーションが壊れた回数はどれくらいですか。

最初のオプションを使用してコンテンツに特定のメディア タイプを与えることにより、サーバー開発者は application/vnd.mycompany.userV2+xml と呼ばれる新しいメディア タイプを導入でき、コンテンツ ネゴシエーションを使用して、既存のクライアントは引き続き元のメディア タイプと新しいメディア タイプを受け取ることができます。クライアントは、新しいメディア タイプを使用するように構築できます。エンドポイントとメディアタイプが結合されていないため、URL は同じままで、ブックマークは壊れていません。

Url のリストとそれらの URL から返されるコンテンツを提供する API ドキュメントを見た場合、それらの開発者は REST を取得できず、RESTful インターフェースが提供する利点を得られない可能性があります。皮肉なことに、最も苦しむのは開発者ではなく、API とやり取りしようとするサードパーティです!

于 2009-08-10T15:38:58.187 に答える
1

これは、複数のクライアントからCRUD機能にアクセスする場合に適しています。私たちはしばらくの間、このようなことをしてきました。あなたを助けるかもしれないいくつかの実装の詳細。

  1. 単にHTTP呼び出しで十分です。RESTを気にしないでください。RESTfulになるには、（READの場合はGET、createの場合はPUTなど）のようなルールに従う必要があります。GETを使用するだけで、ブラウザで簡単にテストできます。XSLTを使用して、応答をHTMLのテーブルにフォーマットします。

  2. 1つのXMLスキーマを使用してすべての応答を処理します。これは基本的にSQL結果のXML表現であり、複数の結果セット、影響を受ける行、エラー応答、リターンコードなどを処理するのに十分な柔軟性が必要です。

  3. XMLのJSON表現を使用して、Javascriptでの処理を容易にします。

  4. また、SQLバックドアを追加して、任意のSQLステートメントをデータベースに送信できるようにしました。これはデバッグに非常に便利です。この種の呼び出しには、ある程度のセキュリティが必要です。私たちはそれをオフィスネットワークにのみ公開します。

于 2009-08-10T08:49:46.197 に答える
1

純粋なデータ層について、トランザクションのサポートについて考えたことはありますか?

  • トランザクションをサポートする必要がありますか? もしそうなら、それらはどのように実装されますか？
  • トランザクションは複数の HTTP リクエストにまたがりますか? (純粋な REST 実装の場合、自明ではない操作に対して複数の呼び出しがあると思います。) たとえば、1 つの口座を引き落とし、別の口座を貸方記入します。
  • 誰が取引を管理しますか?

現在、トランザクション制御が必要ない場合、将来的に必要になる可能性はありますか? それはあなたのデザインにどのように影響しますか？

答えよりも多くの質問。:) しかし、考える材料です。

アップデート：

選択した言語（あなたの場合はJava）と必要なその他のライブラリ（ORMなど）を使用して、標準のデータアクセスレイヤーを作成します。データ アクセス層の設計が既にある場合は、アプリケーションをシンプルに保つためにそれに従います。これを外部に (さまざまなクライアントに) 公開したい場合は、サービス/ビジネス レイヤーと呼ばれるものでこれを行います (機能が単純で、再利用の可能性がない場合は、両方を 1 つの実装に折りたたんでも問題ないでしょう)。そこでは、セキュリティ（認証、承認など）、データ検証を処理し、内部データ表現と外部表現の間のマッピングを実行する可能性があります。その後、URL ベースの API に従ってサービスを公開できます。

同じことを話しているのかもしれませんが、セマンティクスが異なるだけです。

于 2009-08-10T07:19:19.890 に答える
0

Java ソリューションをお探しの場合は、Restletsをご覧になることをお勧めします。XML-RPC と REST スタイルのアーキテクチャがほとんど混在しています。 RPC と REST の違いは次のとおりです。
RESTful な方法で行う場合は、XML を渡す代わりに URI を使用してアクションとパラメーターを決定する必要があります。

于 2009-08-10T07:13:38.153 に答える