問題タブ [restful-architecture]

RESTful Web サービスを作成しており、一部のリソースは計算機能または処理機能です。たとえば、ユーザーは、画像を送信し、スケーリングまたは変換された画像を受け取ることで、API を介して画像のスケーリングと変換を行うことができます。

RESTful Web Services Cookbookのセクション 2.5 によると、 GET を使用する必要があります。

これは、入力が単純​​な場合 (ポイントの経度/緯度座標など) では明らかです。ただし、画像などのより大きな入力についても同じアドバイスに従う必要がありますか? 私の知る限り、これほど多くのデータをクエリ パラメータとして送信することはできません。

RESTfulアプリケーションでは、2つのリクエスト間で状態が維持されません。同じユーザーから送信された場合でも、各リクエストは完全に新しいリクエストとして扱われます。つまり、セッションはありません。

その場合、ユーザーログイン情報はRESTアプリケーションによってどのように処理されますか？

1. それは、ログインが成功した後、サーバーがセキュリティトークンを生成してクライアントに送信し、クライアントがその後のすべての要求に対してそれを送り返すということですか？
2. 上記が当てはまる場合、セキュリティトークンはサーバーのどこに保存されますか？データベース？（覚えておいてください：セッションはありません）。

Entries と呼ばれるリソースがあります。これには、リソースに付随する通常のデフォルトの RESTful ルートがすべて含まれています。showアクションを Articles コントローラー ( ) に再ルーティングすることを除いて、すべてのルートをそのままにしておきたいですArticles#show。これが私のルートファイルの現在の（しかし機能していない）コードです：

この問題を解決する方法についてのアイデアはありますか? Entries リソースからの他のすべてのルートをそのままにしておきたいと思います。

RESTful Web サービスの実装と RESTful API の作成について読み始めたところです。REST の基本的な概念は理解しましたが、安全に実装する方法について頭を悩ませています。

たとえば、私の webapp にユーザー ログイン プロセスがあるとします。ログインに成功したら、サーバーで認証するために RESTful リクエストで他に何を渡す必要がありますか? 私が考えることができるのは、次のプロセスです。

• ユーザーのログイン (POST ユーザー名/パスワードを API に)
• API はユーザーキーで応答します
• ユーザーキーはローカルに保存されます
• さらにリクエストを行うときは、このキーを認証リクエストに含めます

しかし、ここではuserkeyAPIに送信している状態のようですが、RESTはたまたまステートレスです。GETまた、リクエストを送信する場合、これはあまり安全ではありません。

OAUTH は私のジレンマの解決策ですか? それとも他の方法ですか？誰かがこれについて私を案内できますか...

ありがとう

当社では、ベスト プラクティスとして、Contract-First アプローチを使用して Web サービスを作成しています。

WSDL は、実装が検討される前に定義されます。

RESTを使用してそのようなアプローチを使用することは可能ですか? XSD を使用することを考えていましたが、呼び出しは通常 XML ではありません。では、機械が解釈できる方法でコントラクトを指定するにはどうすればよいでしょうか。

Spring MVC 3.0 で実装されたアプリケーションを既に持っています。ここで、ビジネスロジックが1つのアプリケーションに残り、Webレイヤーが別のアプリケーションに残るように、このアプリケーションを安らかなアプリケーションに変換したいと考えています。

Rest を使用してこれを実現するために、Web レイヤーは REST クライアントとして機能し、ビジネス ロジックの実装に関連するアプリケーションによって公開されるサービスにアクセスします。

私が混乱している点は、このためにログインをどのように実装する必要があるかです。

REST POST リクエストで Web アプリケーションからサービス アプリケーションにログイン資格情報を送信し、その後のリクエストを承認する jsessionid として機能する ID を維持する必要がありますか?

または、すべてのリクエストを認証して承認する必要があります

または、この種の要件を達成するためにSpringによってすでに提案されている設計パターンはありますか。

これについての知識を持っている人は誰でも私を助けることができますか?

AppEngineを一種のRESTfulWebサービスとして使用しようとしています。このサービスは簡単な検索と書き込みを行うことになっているDatastoreのでObjectify、その部分をカバーするのに適しているようです。Datastore'. I'm usingまた、その部分のRedstone XMLRPC`でデータが利用できない場合は、他のサービスへのルックアップもいくつか行います。

ここで、AppEngineの割り当てを考慮してサービングパーツを設計する方法についていくつか質問があります（ほとんどの場合、効率について考える必要がありますが、AppEngineの請求により、より多くの人が効率について考えるようになります）。

1. まず、単純なを使用することを考えてみましょうServlets。この場合、2つのオプションがあります。それぞれにJsonが渡された異なるサービスを提供する多数のサーブレットを作成するか、単一の（または少数の）サービスを使用して、Jsonで渡されたパラメーターに基づいて実行するアクションを決定します。どちらのデザインも、クロックされる時間数などに意味がありAppEngineますか？

2. ベアボーンアプローチなどのRESTfulフレームワークを使用する場合、RestletまたはそれRestEasyとは対照的に、コストの違いは何ですか？

この質問は、次のフォローアップのようなものです：GoogleAppEngineを使用したJavaWebサービスの作成

私の RESTful API クライアントでは、データベースに既に存在する情報を投稿しようとする場合がありますが、これはエラーではなく、クライアントが無視できるものであり、既存の複製についてユーザーに通知する可能性があります。

今、私は 409 Conflict を返し、応答本文に既に存在するオブジェクトを返しています。次の理由から、それは正しくないと思います。

リソースの現在の状態と競合するため、要求を完了できませんでした。このコードは、ユーザーが競合を解決してリクエストを再送信できると予想される状況でのみ許可されます。応答本文には、ユーザーが競合の原因を認識するのに十分な情報を含める必要があります。理想的には、応答エンティティには、ユーザーまたはユーザー エージェントが問題を解決するのに十分な情報が含まれます。ただし、それは不可能な場合があり、必須ではありません。 restpatterns.org経由

一般的に、409 は PUT に関連しているようです。

この場合の正しい対応は？303 See Other and Location ヘッダーでしょうか？

私は最初のアプリをレールで書いているところですが、次のことを行うためのベストプラクティスがあるかどうか疑問に思います。

私は足場によって作成された顧客モデルを持っており、それをポンプでくみ上げています。顧客はグーグルマップに表示されなければならないので、/ customers / 23に行くと、顧客情報が表示されます。さらに、このページ内に、ユーザーをマップに表示するためのリンクがあります（ajax経由で表示されるクエリUIダイアログを使用）。私にとっての質問は、これがモデルの通常のクラッド構造にどのように適合するかということです。「show_map」というアクションを作成して、リソースルートに追加のルートを追加する必要がありますか？このようなことをどのように処理しますか？