RESTfulであることはそれほど重要ですか?[閉まっている]

Question

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

現時点では、クライアントとサーバー間の通信は、正常に動作するシステムを介してのみ POST 経由で送信されます。REST と、PUT、GET、POST、DELETE を使用した HTTP での RESTful について、かなりの情報を読みました。API をこれらの異なるカテゴリに分類することもできますが、コードが増え、API にいくつかの変更が加えられることになります。

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

前もって感謝します。

Answer 1

として 筋金入りのRESTafarian HTTP (問題の REST プロトコル) を最大限に使用することをお勧めします。なぜ？さて、昨日、私の友人と交わした電子メールの抜粋を 2 つお見せします。その友人はとても賢い人です (元 IT の教授で、今でも講義をしており、どこへ行っても元気いっぱいです)。

昨日、私はMappodrhomの重要なマイルストーンを通過しました
応用：これで、長期にわたるバックグラウンド計算を起動できます
ワーカープールに。彼らが終了すると、労働者は結果を直接残されたリソースに戻します。より多くのバックグラウンド処理をトリガーし、すべて依存関係グラフによって制御されます。

そして興味深い側面は、この安らかな背景が
実際に私の特定のアプリケーションから独立しています。でも私はそうよ
現在、疲れすぎて結果を完全に把握できません:-)

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

これが私自身の経験を交えた私の返信です。

これは聞こえると思います（私のフランス語をご容赦ください）f ***すごい！私は自分の休憩所で同様のことを経験しています。中層は非常に薄くて透明であるため、インフラ構造についてあまり心配することなく、必要な方法で拡張することができます。それは私の脳が爆発することであるようなキックアスクールなことであり、なぜそれをしていないのかに対する心配な好奇心です。

要するに、RESTを実行すると、 中途半端なだけ 実際にはまったくやっていないのと同じです。あなたは、自分のものを別のパイプラインに移しているだけで、ステートマシン、セマンティクス、および実装を中核で切り離し、ネットを構築した原理に基づいて動作する、簡素化された API を見逃しています。実証済みのアイデアが裏にあります)、統一インターフェイス、モデリングの一部として URI を使用することなどです。

自由に選べる、すべては単なるオプションだ、ということがよく言われるのは承知しています。そうではありません。 RESTのみが意味をなす それを最大限に活用することで、実際にもう少し頭を使って何か賢いことをするよう説得するには、あえて FUD を突破することしかできません (すべて RPC に関するものであり、必要なのは GET と POST だけであり、必要はありません) JSON、SOAP、その他の類似物などに相当するすべてが必要です)、アプリケーションの作成方法についてより賢くなります。 はい、皆さんもぜひ！

Answer 2

あなたはハイパーメディアを活用しようとしている場合を除き、私はRESTの制約に準拠しようと気にしないでしょう。ハイパーメディアは、その部品の合計よりも大きいシステム作るパズルの一片である。

あなたが選ぶ、あなたのアーキテクチャに尊重したいREST制約のどの自由に選択できます、ちょうどそれは、RESTfulな最終結果を呼び出すことができるように注意して、唯一のオプションの制約は、「コードのダウンロード」である。

Answer 3

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

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

REST には素晴らしい理想が隠されていますが、それはアプリケーションに REST API を提供する必要があるという意味ではありません。追加の努力に見合った利益が得られない場合は、気にする必要はありません。

Answer 4

これはお勧めです。私はあなたがHi-休息とLo-RESTと呼ばれるものがあるように移動する必要がありますどのようにRESTfulには触れませんでした嬉しいです。あなたはグーグルからのより多くの情報を得ることができます。いくつかの業界のベテランは、私はこれについてあまりないように注意してください知っているが、私は、HTMLの近くに滞在し、HTTPが長期的にお手伝いをし、多くのことを簡素化します見つけるのですか。

Answer 5

私はそれが必須を持たなくていいということ提出します。私の経験では、このアーキテクチャを追加するプロジェクトの範囲と複雑さを増すが、それは全体の優雅さの度合いを追加しません。あなたがプロジェクトの時間と予算を持っている場合、私はそれについて心配しないではない場合、それのために行く、と言うでしょう。

Answer 6

サービスAPIのに考慮すべき事柄（多くの）一つは、彼らがエンドユーザーによって消費することができる容易さです。 RESTは非常に強力なツールの存在感を増しています。

これまでの.NETのdevのグループがあるうちの最大のdevのGROUP BY、およびLINQのは非常にシンプルで非常にエレガントで使用してRESTを消費するサービス（アストリア）のためのADO.NETでます。