4

私は同僚と話し合いました。彼は本当に REST をとても気に入っていますが、それでも私はその利点を確信する必要があります。

私の主な問題は、消費するアプリケーションの観点から、REST を API または一般的なインターフェースとして実際に見ていないことです。詳しく説明しましょう。RESTful API を使用して一方が他方を呼び出す 2 つのアプリケーションがあります。これは、JAX-RS と RESTeasy を使用して実装されます。ただし、RESTeasy を使用すると、インターフェースに基づいて REST クライアントを生成することも非常に簡単です。

では、本と著者を扱うシステムだとしましょう。アプリケーションは本について知る必要があり、すでに何らかの ID を知っていると仮定しましょう。

  • REST では、たとえば を呼び出しhttp://server/book/21、任意のペイロードを返し、それをBookオブジェクトに逆シリアル化します。
  • RESTeasy クライアントを使用するBookServiceと、メソッドとのインターフェースがありBook getBook(int bookId)、単に呼び出してオブジェクトgetBook(21)を返すだけです。Book

私がしようとしているポイントは、それBookServiceが明確に定義されたインターフェースであり、(プログラマーとして) 期待される引数が識別子であり、Bookオブジェクトを返すことを簡単に確認できることです。"just REST" を使用して URL にアクセスすると、任意のデータが返されます。明確に定義されたインターフェースがなく、サーバーからの内部 URL 情報を知らずに URL を構築する方法がわからず、XML を「手動で」解析する必要があります (できれば XSD を使用します)。

別物。私は本と著者に言及しました。

BookServiceインターフェイスを使用する場合は、返されるBookとAuthorService返される のみを持つことができますAuthor。ABookはプロパティを持つことができ、を呼び出すことauthorIdでオブジェクトを取得できます。AuthorAuthor getAuthor(int authorId)

REST を使用する場合、書籍の URL を呼び出すと、著者へのリンクなど、著者に関する情報が返されます。次に、リンクをたどって、著者に関する詳細情報を取得します。しかし、このリンクがどこにあるのかを正確に知るにはどうすればよいでしょうか? そして、以前と同じ質問が発生します: リンクを構築する方法、返されたデータを解析する方法を知るにはどうすればよいですか?

そして、2つを混ぜると、奇妙なことが起こる可能性があります. BookIDだけを取得したい場合は、 BookService(内部的に REST 呼び出しに変換される) を呼び出して、適切なBookオブジェクトを取得することができます。しかし、著者情報を取得したい場合はString authorLink、オブジェクトを取得するために従わなければならない this がありAuthorます。しかし逆に、開始点が であり、Authorを使用して取得すると、AuthorService書籍オブジェクトを指す文字列 (URL) のコレクションで、著者が書いた書籍へのリンクが取得されます。

では、なぜ REST が API と見なされるのでしょうか。適切に定義された (Java) インターフェースよりも REST を優先する必要があるのはなぜですか? そして、どうすれば2つを混在させることができますか?

4

7 に答える 7

3

なんらかの理由で、Roy Fielding が構想した方法で REST を使用している人は誰もいません。したがって、それは非現実的です。怠惰な人にとっては、それについて考える必要がないのに十分です。

どうやら、業界は RPC のさまざまな名前を考案することに夢中になっているようです。

于 2012-09-17T21:58:33.407 に答える
2

選択した検索エンジンでHypermedia APIをチェックしてください。

どのリクエストで何を呼び出すかを「知る」方法を説明する優れた文献がいくつかあります。特にハテオス。

ハイパーメディア API を使用する理由 REST は、かなり緩い骨抜きの用語です。多くの場合、正しく実装されていません。この混乱を解消しようとする動きが最近急増しているため、「新しい」用語が使用されています。正しく行われると、Java/.NET で強く型付けされたサービス (ala SOAP、RPC) のようなものを使い慣れた素敵なスタイルのインターフェースを備えた REST (Hypermedia API を参照) サービスのパワーを得ることができます。

于 2012-09-17T21:41:23.507 に答える
1

REST は API ではなく、アーキテクチャに近いものです。REST は、既存の HTTP プロトコルを介して 2 つの異なるシステム間で通信するために使用されます。REST は多くのことに非常に適しています。おそらく、REST を使用する必要はありません。

于 2012-09-17T21:43:13.717 に答える
0

分散アプリケーション/システムを構築するためのツールについてREST（デザインやコーディングスタイルではなくアーキテクチャ）について考える場合、アプリケーションの状態を管理するために（ワールドワイドウェブ上で）よく知られた実証済みの概念を使用することが主な目的であり、それを使用することは理にかなっています場合によっては。

あるアプリケーションからリモート ホストに処理/計算を移動したい場合 (書籍のリストを取得するとします)、メソッド呼び出し (GetBooks) を SOAP メッセージにシリアル化し、そのメッセージを http リクエストなどに追加することで実行できます。 . または、単に GET /books を呼び出すこともできます.. 場合によっては、2 番目の方法で ti を使用する方がはるかに安価です。明示的に実装されているのではなくインフラストラクチャの一部であるリソースキャッシングや、同じリソースの異なる表現が必要な場合の柔軟性など、他のことについて言及した場合、それはさらに理にかなっています。

一部のサービスが REST スタイルを使用し、それが (他の API のように) 慎重に記述されている場合、理解して使用するのは簡単です。また、これらの種類のサービスは、JAX-WS や WCF のようなフレームワークがないさまざまなタイプのクライアント (javascript、php、..) から簡単に利用できます。

簡単にするために、REST サービスを本棚と考えることができます。そこから本 (リソース) を入手でき、そこから新しい本を投稿したり、入手した本を置くことができます..各リソースが問題のドメインに関して意味を持っている場合、およびリソース表現には、関連リソースへのリンクが含まれていますが、それを理解/消費する問題はわかりません。

于 2012-09-17T22:35:20.987 に答える
0

REST の重要な部分を誤解しています。適切に設計された RESTful システムでは、次の 2 つのことを十分に文書化する必要があります。

  1. システムとの対話を開始するために使用するエントリ ポイント (または「クールな」URI)
  2. リクエスト内で送信され、レスポンス内で返されるペイロード データのスキーマ (HTTP 用語では、これらはメディア タイプです)

この 2 つだけを教えていただければ、RESTful API のクライアントを構築できます。#1 から始めて、#2 の知識を使用して、システムの API "ハイパーリンク" を回避する方法を見つけることで、必要なリソースを見つけることができます。

あなたのシステムのBook表現を知っていれば、GET 呼び出しを行ってそれを取得して理解するか、POST または PUT 呼び出しを行って作成することができます。HTTP はこれらの動詞をすぐにサポートします。ネットワーク経由で何が送信されるかを知る必要があるだけです (そして #2 が教えてくれます)。

XML が気に入らなければ、代わりに JSON を話せるかどうかをサーバーに問い合わせることができます。HTTP は、そのままでその種のコンテンツ ネゴシエーションをサポートします。

REST はユニコーンが作った魔法の妖精の粉ではありません。REST を使用するだけで問題が解決するわけではありません。ただし、これは、実績があり、よく理解されている、スケーラブルで柔軟な既存のテクノロジとアプローチを利用しようとする常識的なアーキテクチャです。

于 2012-09-18T01:54:07.230 に答える
0

簡単に言うと、REST API は他のプログラミング言語に対して柔軟です。

RESTEasy には詳しくありませんが、RESTful サービスには精通しています。REST には標準がありません。ほとんどの REST サービスは、REST API と対話する方法を公開しています。利用可能な URL (リソース)、送信されるコンテンツ タイプ、および返されるタイプ。良いものは、返される http ステータス コードとエラーの処理方法も公開します。あなたの場合、REST Easy クライアントが何をしているのか正確に知りたいです。API 呼び出しを HTTP リクエストに変換し、開発者のためにすべてを処理するだけですか?

REST API 呼び出しを文書化し、すべてのモデルを含む jar ファイルを提供します。モデルは JAXB アノテーションを使用するため、開発者は、サービスから返される XML または JSON についてすべてを知る必要はありません。それは、彼らが Java と私たちのモデルを使用している場合です。API を公開して文書化することの良い点は、他の言語の開発者が HTTP 要求を作成できればサービスを使用できることです。これにより、開発者はほぼすべてのプログラミング言語でクライアント アプリを開発できます。(最近は C# の実装が増えているようです)。

モデルの jar ファイルを提供することに加えて、非 Java 開発者向けのドキュメントで XSD を提供しています。

于 2012-09-17T22:08:59.847 に答える
0

ReSTAPI ではなく、アーキテクチャ スタイルです。

ReST を使用して得られるいくつかの利点

  1. 複数の応答タイプの機能 (例: JSON、XML) ReST は SOAP のように XML にバインドされていません
  2. JSON を使用すると、ペイロードが軽量になり、サービスが高速になります
  3. 開発とテストがはるかに簡単
  4. ReST はプレーンな HTTP を使用するため、プロキシ関連の問題はありません

サービス定義に関してはwadl、ReST サービス用にファイルを生成して、完全なオプションを表示することができます。ほとんどのサーバーはこれらを自動生成します。SOAP であろうと ReST であろうと、サービスは十分に文書化する必要があります。LinkedIn ReST APIを確認できます。

SOAP の唯一の利点は、SOAP が提供できるセキュリティ機能です。しかし、すべてのアプリケーションがそのレベルのセキュリティを必要とするわけではありません。

于 2012-09-18T11:12:47.400 に答える