これはRESTFUL APIを実装していますか？

Question

これは奇妙な疑問のように思えるかもしれませんが、他のいくつかの開発者の意見を得たいと思っていました。これは私たちが直面しているかもしれないいくつかの潜在的な特許問題を思い付いています。

私は、T秒ごとに私たちのサーバーをポーリングする電子デバイスをインターネット（顧客サイトにインストール）に持っています。各デバイスは、固有のシリアル番号とURL、各デバイスのポーリングが（URLの末尾にあるシリアル番号に基づいて）ユニークであります

ポーリングT秒毎：

http://example.com/device/SERIAL_NUMBER

当社のサーバーだけ"0"または "1"を返します。文字通り、URLにヒットすると、ブラウザに0または1が表示されます。

この「0」または「1」は、デバイスの電源をオンまたはオフにするだけです。基本的には、デバイスをオン/オフするためのリモートスイッチです。私たちが0を返したら、1を返すと消えます。

ノーJSON、XMLなし、ただ0または1

は、このいずれかの方法で「RESTfulなAPI」で、純粋な/最も単純な形で、と考えられます。

私は考えていますが、HTTPを使用して一意のURLをポーリングし、オン/オフのバイナリを返すだけです。一方、リスタフルなAPIを持つためには、 URLと少し返す。

ありがとうございます！

Answer 1

"少し送信"する必要はありません。

Github API

レスポンスこのリポジトリは、あなた

GET /user/starred/:owner/:repo 
Status: 404 Not Found 

で主演されていない場合は、このリポジトリは応答

GET /user/starred/:owner/:repo 
Status: 204 No Content 

自分で主演した場合

これは、REST APIとしては非常に興味深いものではありません。この特定のアプリケーション状態がプロトコルの終了状態であることを示しています。さらなる進化のためのアフォーダンスとして機能する表現はありません。 Fielding's dissertation

残りから

は、4つのインタフェースの制約によって定義されるリソースの識別。表現を通してのリソースの操作。自己記述的なメッセージ。アプリケーション状態のエンジンとしてのハイパーメディア。

Answer 2

これは、どのような方法 "RESTfulなAPI" で、純粋な/最も単純な形で、と考えられます。

TL; DR

技術ありません。法的には違う問題です。レイヴァーがいるところには方法があります。 IANAL。

根拠用語と

問題RESTとRESTfulはRESTは建築パターンはなく、詳細な仕様を定義するため、その定義は、抽象的で当然のようになることです。その言葉を作ったRoy Fieldingによると、RESTはいくつかの特性と制約によって定義されています。

あなたの質問に答えるために、一般にRESTfulシステムと見なされるものを理解する必要があります。次に、あなたのシステムがこの定義と一致するかどうかを評価することができます。

定義

プロパティ

プロパティは、システムのアーキテクチャのobserveable効果を示しています。プロパティーはシステムのアーキテクチャー、設計、実装の結果であり、RESTfulシステムは通常、これらのプロパティーの少なくとも大部分を達成することが期待されます。しかし、私は、これらの特性の単なる存在は、それを達成するための他の方法があるため、システムの「安心感」の指標ではないことを主張します。

• パフォーマンス - コンポーネントの相互作用は、成分のうち大型部品の数との相互作用をサポートするためのユーザ知覚パフォーマンスとネットワーク効率
• スケーラビリティにおける支配的な要因であることができます。
• データとプログラムコードを移動することによって（アプリケーションが実行中であっても）成分の
• サービスエージェントによってコンポーネント間の通信の可視性
• ポータビリティを変化するニーズを満たすために部品の統一されたインタフェースの単純
• 修正可能
• 信頼性コンポーネント、コネクタ、またはデータ内の故障の存在下で、システムレベルでの障害への耐性である

出典：

制約は、システムのアーキテクチャの（必要かつ十分な）要素を定義しているWikipedia

制約。システムがこれらの制約のいずれかに違反した場合、定義によってはRESTシステムと見なすことはできません。したがって、制約は、システムのRESTfulnessのより強力な指標です。

• クライアントサーバー - クライアント - サーバ間の通信がされていないクライアントコンテキストによって制約される - （...）懸念の分離は、クライアント - サーバの制約（...）
• ステートレスの背後にある原理は、要求の間にサーバーに保管されます。
• キャッシュ可能 - ワールドワイドウェブと同様に、クライアントと仲介業者が応答をキャッシュすることができます。
• レイヤードシステム - 通常、クライアントはエンドサーバ（...）に直接接続しているかどうかを判断できません。
• オンデマンドコード（オプション） - サーバは、クライアントの機能を一時的に拡張またはカスタマイズすることができます。実行可能コード。
• ユニフォーム・インターフェース - リソースの識別、表現を介してリソースの操作、自己記述メッセージ、ハイパーメディアアプリケーション状態のエンジンとして

出典：Wikipedia

評価

プロパティ

• パフォーマンスはい一般的な意味では、システムのパフォーマンスはネットワークのパフォーマンスに依存します（ネットワークのパフォーマンスが悪いと、デバイスのオン/オフの切り替えがまったく行われない、またはまったく動作しないことを意味します）。
• スケーラビリティ-はいは明らかに、システムは任意の数のデバイスにスケーラブルであり、明らかにデバイス自体に影響を与えません。
• 統一されたインタフェースの簡略化 - YES、各デバイスのURI
• 修正可能 - YES、両方のデバイスとサーバが他の影響を受けること
• 可視性なしに変更することができる - YES、はっきり通信が見えます少なくともあるレベルで
• 移植性YES 0/1命令は実行可能コードです（デバイスのステートマシンはこれをアクションの実行につなげるイベント、つまりスイッチをオフにする）
• 信頼性 - MAYBE、我々は十分に

お使いのシステムについての結論を知らない：お使いのシステムには、RESTfulな設計のほとんどの特性を示すが。これは実際にはRESTfulであることを示すのに必要なものですが、十分ではありません。それでは、次のcontraintsを調べてみましょう： - ：、/オフ各デバイスごとにスケジュール

制約

• クライアントサーバーYES、明らかにこれは、クライアント・サーバの設計である、との懸念は、（サーバーを分離していますデバイス：効果のオン/オフアクション）
• ステートレス - YES、サーバーにクライアントコンテキストが保存されていません。これは、デバイス状態ではなく、通信状態を参照していることに注意してください。
• キャッシュ可能 - YES、これは通信プロトコル
• 階層システムとしてHTTPを使用に固有のものである - これはコード・オン・デマンド（オプション）
• 通信プロトコルとしてHTTPを使用して固有のYESある - YESは、上述のように、0/1命令は実際には実行可能コードとみなすことができます。
• 統一インタフェース - NOは、リソースが明確に識別されますが、操作は不可能であり、クライアントがリソースのナビゲーションを許可するハイパーメディアは存在しません。

結論：と記載されているシステムでは、はRESTアーキテクチャ状態のすべての制約を満たしていません。つまり、統一されたインターフェイスは要求されたエクステントに一致しません。これは、均一なアドレッシングスキーム（URI）を提供しますが、RESTユニフォームインターフェイスの他の要素を満たしません。お使いのシステムの説明の中で結論

、プロトコルおよび各デバイスごとに一意のURIとしてHTTPを使用することは確かに効果RESTfulなシステムの必要なプロパティのほとんどは、これだけではない間必要な制約がすべて満たされているわけではないため、RESTfulと見なすには十分なが必要です。