RESTおよび/またはRESTfulアプリケーションのいくつかの定義と説明を読みましたが、それでも本当の意味がわかりません。
私は通常、GETを介してデータをフェッチするか、POSTを介してデータをいくつかのWebサービスに送信するアプリ(通常はPHPスクリプト))を使用して、データを取得するアプリを使用しますデータベースから、またはデータベースへの書き込みを行います。
さて、これはRESTfulアプリですか?そうでない場合、RESTfulアプリは何でしょうか? RESTfulコンセプトとこれまでに使用したコンセプトの違いは何ですか?例を挙げて説明してください。
また、誰かがRESTおよびRESTfulアプリについての誰かについて話している。私はREST用語が理論上の概念を指しているのに対し、RESTfulは特定のアプリについて話します。これは正しいですか、RESTとRESTfulアプリの間に実際の違いがありますか?
RESTfulアプリケーションの主要な属性は次のとおりです。すべての通信はhttp GET、POST、PUT、DELETEを介して行われます[〜#〜] and [〜#〜]すべてのアイテムは、フォームの標準URLを介してアドレス指定されますhttp://your.site.com/salesapp/salesperson/0000001/details
つまり、パラメータを持たない純粋なURLなどのみです。URLは、GET、POST、PUT、DELETEが実行したいことを識別します。
これを行う主な理由は、負荷分散やフェイルオーバーなどが可能なステートレスサービスが自動的に提供されることです。
スキームの単純さにより、非常にクリーンなインターフェースが実現し、特定のバックエンド実装からクライアントを完全に切り離します。
RESTは、Representational State Transferの略です。ソフトウェアが REST制約 に準拠している場合、RESTfulと見なされます。
右、私はウィキペディアから恥知らずに引き裂いたので、これは本当に何を意味するのでしょうか?これは、GET、POST、PUT、DELETEなどの組み込みのHTTPコマンドを使用して、クライアントとサーバー間でやり取りすることを意味します。
あなたがやっていることは、そのRESTFulアプリのように聞こえます。ただし、適切に設計されたものと山積みのジャンクRESTFul Webサービスとの間にはlargeの違いがあります。たとえば、GETの反対側にあるPHPコードは状態変更を実行する可能性がありますが、GETは読み取り専用操作と見なされるため、これは間違っていると見なされます。 POST(新規)とPUT(置換)の使用方法にも微妙な違いがあります。
これに関するウィキペディアの記事は実際には本当に良いので、ここで終了します。
先に進む前に、 この関連する質問が役立つかもしれません
RESTとRESTfulの違いは、単にセマンティクスです。 RESTは、クライアント/サーバー関係に適用されるアーキテクチャスタイルです。 RESTfulは、RESTを使用していることをクライアントに伝える方法です。
多くのWebアプリケーションはRESTfulであると主張していますが、 実際には部分的にのみ準拠していますREST制約 に準拠しています(Martijn Verburgも彼の回答で参照しています)。ここではそれらのみをリストしますが、記事を読むことを強くお勧めします。
あなたがクライアント側で作業していると述べたので、RESTアーキテクチャが接続クライアントとしてあなたに与え、期待するものを理解することは役立つかもしれません。 RESTはHTTPではありませんが、RESTが何であるかをサポートする最も一般的なプロトコルです。
クライアントは次のことを期待されます。
<link rel="pay" href="http://example.org/orders(1)/payment">
がPOSTを介して支払いリソースを作成するための状態遷移を表すとユーザーまたはアプリケーションに推測させますクレジットカード番号、金額などの支払いの詳細を表すXMLを含む本文)上記を実行する場合、RESTクライアントと見なすことができます。「RESTfulアプリ」と呼ぶこともできますが、これはRESTを使用していることを意味します_クライアント側では正しくないため、用語を回避するのが最善です。
RESTfulとは、インターフェースが一連のオブジェクトであり、読み取りと更新(場合によっては削除)が可能なオブジェクトであることを意味します。つまり、マルチパラメータークエリはなく(パラメーターのみが読み取りたいオブジェクトです)、サーバー上で何かを変更する操作の種類は1つだけで、新しい状態のアップロードです。
これらの制限により、すべてのリクエストがべき等であることが保証されます(リクエストを複数回送信しても、1回送信するだけの特別な影響はありません)。ネットワークはいつでも障害を起こしてリクエストやレスポンスを配信しない可能性があるため、これは重要です。べき等のリクエストでは、再度送信するだけで、複雑なリカバリを行う必要はありません。