5

サーバーとクライアント間で通信するためにJSONoverHTTPベースのAPIを使用するWebベースのアプリケーションに取り組んでいます。目標は、このWebサービスを通じて共有される同じオンラインデータを使用して、さまざまな目標(オンラインWebクライアント、オフラインデスクトップクライアント、またはサードパーティが作成)で複数のクライアントを開発できることです。

現在、クライアントとサーバー間の通信は、正常に機能するシステムを介してのみPOSTを介して送信されます。私はRESTと、PUT、GET、POST、およびDELETEを使用してHTTPでRESTfulであることに関するかなりの情報を読みました。APIをこれらの異なるカテゴリに分類することもできますが、それはより多くのコードとAPIへのいくつかの変更を意味します。

私の質問は、HTTPベースのAPIがRESTfulであることがどれほど重要かということです。それは推奨事項ですか、オプションですか、それともほぼ必要ですか?

前もって感謝します。

4

6 に答える 6

14

頑固なRESTafarianとして、HTTP(問題のRESTプロトコル)を最大限に活用すると思います。なんで?さて、私は昨日、真剣に賢い(そして以前はITの教授であり、今でも講義をしていて、どこへ行ってもお尻を蹴る)私の親友とのメール交換からの2つのスニペットを紹介します;

昨日、mappodrhomアプリケーションの重要なマイルストーンを通過しました。これで、
長時間実行されるバックグラウンド計算
をワーカープールで起動できるようになりました。終了すると、ワーカーは結果を直接RESTリソースにPOSTバックします。これにより、より多くのバックグラウンド処理がトリガーされ、すべて依存関係グラフによって制御されます。

そして興味深い点は、このRESTfulなバックグラウンドが
実際には私の特定のアプリケーションから独立していることです。しかし、私は
現在、結果を完全に把握するにはあまりにも疲れています:-)

問題の結果は巨大であり(これは、多くの小さなスタック、イベント、サービス、アプリを備えたRESTフレームワークであり、すべて独自の検出可能なURIを備え、すべて同じ統合インターフェースを備えています)、拡張性とスケーラビリティの点で、他に類を見ないものです。そのシンプルさ。あなたのアプリケーションが、場所を旅したり、熱いひよこに会ったりすることのない、ちっぽけな小さなものであるなら、ええ、あなたはそれを必要としないかもしれません。しかし、その後、私は同じことを言いました、そして突然、ロシア人の秘密のスパイであるかわいい女の子と一緒にパリへの電車に乗っていることに気づきました、そしてまあ、あることが別のことにつながりました...

これが私の返事です。私自身の経験もいくつかあります。

私はこれが素晴らしいと思います(私のフランス語を許してください)。私は自分のRESTのものでも同様のことを経験しています。中間層は非常に薄く透明なので、インフラストラクチャについてあまり気にすることなく、必要な方法で拡張できます。それはとても自由で、私の脳が爆発するほどのクールなものであり、なぜもっと多くの人がそれをしていないのかという気になる好奇心です。

つまり、RESTを途中で実行することは、実際にはまったく実行しないことと同じです。単純化されたAPIを見逃して、コアでステートマシン、セマンティクス、および実装のデカップリングに移行し、ネットを構築した原則を使用して、別のパイプラインに移行しているだけです(したがって、私はあなたと言います)かなり実績のあるアイデアがあなたの背後にあります)、統一されたインターフェース、そしてモデリングの一部としてURIを持っています。

私はあなたが選ぶことができると言うのが一般的であることを知っています、それはすべてただのオプションです。そうではありません。RESTはそれを完全に使用することによってのみ意味がありますが、実際に脳を少し伸ばして賢いことをするように説得するために、私はあなたにFUDを切り抜けることしかできません(それはすべてRPCに関するものであり、GETとPOSTだけが必要です、 JSON、SOAP、その他の同類のものと同等のすべてを必要とせず、アプリケーションの作成方法についてより賢くなります。ええ、私はあなた方全員をあえてします!

于 2009-05-28T23:36:14.313 に答える
6

ハイパーメディアを利用する場合を除いて、REST制約に準拠しようとはしません。ハイパーメディアは、システムをその部分の合計よりも大きくするパズルのピースです。

アーキテクチャで尊重するREST制約を自由に選択できます。最終結果をRESTfulと呼べるようにするには、オプションの制約は「コードダウンロード」のみであることに注意してください。

于 2009-05-28T23:58:35.330 に答える
1

これは、明確に定義されたAPIを使用してWebアプリケーションをWebサービスとして公開するためのいくつかのオプションの1つです。その他のオプションは次のとおりです。

  1. APIなし-アプリケーションには、他の分散システムのコンポーネントとして使用する実際の方法がありません
  2. SOAP-APIリモート呼び出しを定義するためのXML形式
  3. JSON-カスタムAPI形式を作成するために構築できる(または必要に応じてRESTシステムを構築するために使用できる)情報交換用のコンパクトな形式
  4. 他の多くの形式のリモートプロシージャコールおよび情報交換媒体。

RESTにはその背後にある素晴らしい理想がありますが、それはアプリケーションにRESTAPIを提供する必要があるという意味ではありません。利益が余分な努力の価値がない場合は、気にしないでください。

于 2009-05-28T22:55:45.860 に答える
0

お勧めです。Hi-RestとLo-RESTと呼ばれるものがあるので、RESTfulに入る必要がないことを嬉しく思います。あなたはグーグルからより多くの情報を得ることができます。私が知っている業界のベテランの中には、これをあまり気にしない人もいますが、htmlとhttpの近くにいることは、長期的にはあなたを助け、多くのことを単純化するでしょう。

于 2009-05-28T22:54:21.653 に答える
0

持っているのはいいことですが、必須ではありません。私の経験では、このアーキテクチャを追加すると、プロジェクトの範囲と複雑さが増しますが、全体にある程度の優雅さが加わります。プロジェクトに時間と予算があれば、心配しないでください。

于 2009-05-28T23:00:04.387 に答える
-1

サービスAPIで考慮すべき(多くの)ことの1つは、エンドユーザーがそれらを簡単に利用できることです。RESTは非常に強力なツールの存在感を獲得しています。

群を抜いて最大の開発グループは.NET開発グループであり、サービス用のADO.NET(Astoria)ではLinqを使用してRESTを使用するのは非常にシンプルで非常にエレガントです。

于 2009-05-28T22:54:51.557 に答える