タグ付けされた質問 「web-services」

Webサービスは、ネットワークを介した相互運用可能なマシン間の相互作用をサポートするように設計されたソフトウェアシステムです。

4
マイクロサービスRESTまたはAMQP、どちらの場合
マイクロサービスアーキテクチャに関する多くの記事を読みましたが、AMQPまたはRESTをいつ使用すべきか疑問に思いました。 サービス間の疎結合は良いことであり、その場合AMQPが良い選択であるように思えます。しかし、AMQPを使用する場合、これはRESTエンドポイントが不要になることを意味します(ただし、HATEOASコンセプトが失われることを意味します)。 しかし、RESTは本当に私のサービスを構築するのに良い方法ですか?原因エンドポイントを使用しません...この場合、一方が他方より優れていますか? いつどちらを使用すればよいですか?

3
リソースが見つからない場合、204または404応答を返す必要がありますか?
トーナメントとスケジュールのためのシンプルなRESTfulサービスを開発しています。JSONボディを含むPOSTリクエストを通じてトーナメントが作成されると、トーナメントはに挿入さBiMapれ、DAO実装で次のように宣言されます。 private BiMap<String, Tournament> tournaments = Maps.synchronizedBiMap(HashBiMap.create()); トーナメントが作成されると、それに関連付けられた文字列IDが返されるので、ユーザーはそのトーナメントを将来参照することができます。彼/彼女は次のリクエストを実行して新しいトーナメントから情報を得ることができます: GET http://localhost:8080/eventscheduler/c15268ce-474a-49bd-a623-b0b865386f39 しかし、そのようなIDのトーナメントが見つからない場合はどうなりますか?これまでのところ、204応答を返しています。まあ、ジャージーはnull、そのメソッドの1つから戻るときに私のためにそれをやっています。これは、上記のルートに対応するメソッドです。 @Path("/{id}") @GET @Produces(MediaType.APPLICATION_JSON) public Tournament getTournament(@PathParam("id") String id) { Optional<Tournament> optTournament = tournamentDao.getTournament(id); if (optTournament.isPresent()) return optTournament.get(); return null; } 私の質問は次のとおりです。リソースが見つからなかったので、204: No Content応答を返すことは問題あり404ませんか、それとも代わりに応答でなければなりませんか? それを404に変更する必要がある場合、明らかな質問:メソッドのシグネチャを変更する必要がありますか?これで(タイプTournament)のトーナメントが返されない可能性があるため、メソッドは異なるように見えるはずです。Response代わりに、型を戻り値の型として使用する必要がありますか?
15 java  rest  web-services  http 

3
ASP.NET MVCとREST API + Webページの使用のためのWCF
プログラムによるサービス指向の使用と人間の相互作用の議論は明確だと思います。 しかし、プログラムAPIと同じAPIで接続されたデータを使用するWebサイトの両方を使用するアプリケーションを作成する場合、ASP.NETのみを使用する方が有利でしょうか? ASP.NETとWCFを統合して同じアプリケーションで動作させるのはどれくらい簡単ですか?

5
トランザクションを使用できない場合、エンタープライズ環境でWebサービスを効果的に使用するにはどうすればよいですか?
私が取り組んでいる場所は、いくつかの基本的なルールを確立しようとしています。そして、私たちが現在持っている議論は、コードを再利用するためのローカルライブラリとWebサービスです。Webサービスは、ほとんどの企業で人気のある選択肢のようです。そして、それは、ここの開発者のほとんどが傾いていることです。 深刻な仕事にWebサービスを効果的に使用する方法がわかりません。トランザクションを使用できない場合、どうすれば複数のサービスコールを安全に実行できますか? 通知が必要な特定の条件を満たす顧客をデータベースから取得するcronジョブがあるとします。ファックス、電子メールが送信され、チケットを作成して問題を内部的に追跡します。これは、forループの各顧客に対して発生する3つの異なるサービスコールです。 そこのどこかでエラーが発生した場合、たとえば、ファックスとメールが顧客に送信されても​​、チケットは作成されない可能性があります。さらに悪いことに、このcronジョブにはバグが含まれていて、毎回同じポイントで失敗し、同じ顧客に繰り返しメールを送信する可能性があります。ライブラリがすべてローカルである場合、すべてをトランザクションにラップすることができますが、それはまったく起こりません。ただし、この例ではWebサービスを使用しています。 電子メールとFAXのメソッドは、実際にはデータベースにバックアップされたキューテーブルにデータを挿入します。これは、別のcronジョブプロセスによって処理されます。したがって、「電子メールの送信」および「ファックスの送信」サービスメソッドの呼び出しは、必要に応じて副作用なしで中止できます。 オプションは、このコード全体をWebサービス自体に配置することです。そのため、Webサービス自体は、トランザクションで電子メール、ファックス、およびチケット作成メソッドを呼び出します。ただし、トランザクションを使用するためだけにWebサービスメソッドを作成しています。この1つのcronスクリプト以外のどこからでも実際にこのメソッドを呼び出す必要がある正当な理由はありません。 このメソッドを一般的にどのように処理しますか?

7
固定の小さな語彙がRESTfulサービスの利点と見なされるのはなぜですか?
そのため、RESTfulサービスの語彙には動詞の固定セットがあります。RESTful Webサービスは、HTTPメソッドからこれらを取得します。固定語彙を定義することにはいくつかの利点があると思われますが、私はその点を本当に理解していません。たぶん誰かがそれを説明できるでしょう。 RESTで概説されている固定語彙が、各状態の語彙を動的に定義するよりも優れているのはなぜですか?たとえば、オブジェクト指向プログラミングは一般的なパラダイムです。RPCは固定インターフェースを定義するために記述されていますが、なぜ人々はRPCがこれらの制約によって制限されていると仮定するのか分かりません。RESTfulサービスがそのコンテンツ構造を動的に記述するように、インターフェイスを動的に指定できます。 RESTは、語彙を増やすことなく成長できるという点で有利であると考えられています。RESTfulサービスは、リソースを追加することで動的に成長します。オブジェクトごとの語彙を動的に指定してサービスを拡張することの何がそんなに悪いのでしょうか?オブジェクトでボキャブラリーとして定義されているメソッドを使用し、これらのメソッドが何であり、副作用があるかどうかをクライアントにサービスで説明させてみませんか? 基本的に、サーバー側のリソース構造の記述は語彙の定義と同等であると感じますが、これらのリソースとやり取りするために限られた語彙を使用せざるを得ません。 固定語彙は、クライアントの懸念をサーバーの懸念から本当に切り離しますか?確かにサーバーの構成に注意する必要があります。これは通常、RESTfulサービスのリソースの場所です。動的ボキャブラリーの使用に不満を言うことは、とにかく何らかの方法でこの構成を理解する方法を動的に推論する必要があるため、不公平に思えます。RESTfulサービスは、ハイパーメディアを介してオブジェクト構造を識別することによって実行できる遷移を記述します。 固定語彙が、自己記述型の動的語彙よりも優れている理由がわかりません。これは、RPCのようなサービスで簡単にうまく機能する可能性があります。これは、HTTPプロトコルの語彙が制限されていることの不十分な理由にすぎませんか? 反射 私の考えを私がやったよりも少し良くするためだけに。おそらく汎用のAPIを設計していると仮定します。Web向けではないかもしれません。オブジェクトでこれらのメソッド名しか使用できないと誰かが言ったら、あなたは幸せになりますか?RESTはHTTPに限定されるものではありませんが、作成するすべてのAPI、Web向け、または単純にGET POST PUTおよびDELETEメソッドを含むオブジェクトで構成される状況を考慮してください。そのため、定義したいobject.fooメソッドは不可能です。fooという新しいオブジェクトを定義し、そのGETメソッドを呼び出す必要があります。それが本質的にRESTの仕組みであり、それについて考えるのが少し不快になります。fooが何をするかについての一般的な理解はありません。基本的には親オブジェクトのメソッドである新しいオブジェクトを作成するように強制されました。さらに、APIはそれほど複雑ではありません。より多くのオブジェクトを作成することにより、インターフェイスの複雑さが隠されているだけです。RESTful Webサービスでは、公開しているAPIのコンテキストでは十分である場合とそうでない場合があります。おそらく、Webに面したAPIでこれを行う正当な理由があるかもしれませんが、すべての汎用APIのすべてのオブジェクトに標準インターフェースを採用しない正当な理由があります。実用的な例に感謝します。

3
Webサービスを使用するデスクトップベースのクライアントのオフラインフェールオーバーを実行する最良の方法は何ですか?
共通の問題を共有する次の3つのプロジェクトがあります。 Webシステム上にロジックが必要であり、RESTful Webサービスを介してそのようなシステムと通信するローカルアプリケーション(POSなど)が必要です。 私のソリューション 私が思いついたソリューションは、デスクトップアプリケーションにメッセージキューを実装して、サービスがオフラインである間、より正確には非同期メッセージキューを操作を保存することです。しかし、それは簡単な部分です(もしそれが最良の解決策であるなら)。また、データの同期と競合の解決にも関心があります。 利害関係者によるレポートと監視にはWebアプリが必要であり、Webサービスは複数の施設の要求を処理するため、メインシステムはWebベースである必要があります。 デスクトップクライアント(できればシン)はJava(より具体的にはNetbeans)で実装され、WebシステムはSymfony2で実装されます。2つのプロジェクトにはクライアントのハードウェア統合が必要であるため、Webテクノロジー(Appcelerator Titaniumなど)を使用してデスクトップアプリケーションを作成することは大きな苦痛になる可能性があります。 私の質問 最小の労力で最大の効率を意味する、拡張可能な優れたソリューションとは何ですか(ローカル操作用にバックアップサーバーを購入するなどの追加コストは不要)。 他に誰がこれに対処しましたか?どのようにして問題を解決しましたか?どんな教訓を共有できますか? 同期はどのように対処しましたか? 編集:ポイント#3で私の質問に不足している部分を追加しました

3
webappをデプロイするシステムのヘルスチェックの範囲はどのくらいですか?
今日、Webアプリを展開するオーケストレーションシステムである長期実行サービスの「ヘルスチェックを記述する」タスクがありました。 私はそのようなヘルスチェックの範囲が何であるかを決定しようとしていますが、ヘルスチェックの範囲に関連するこれらの質問を思いつきました: オーケストレーションシステムがタスクの実行を報告している場合、サービスが正常であると考えるのに十分ですか? または、各サービスを手動でpingする必要がありますか? または、さらに進んで、Webページを表示するなど、Webアプリケーションが本来行うべきことを確実に実行しようとする必要がありますか? ヘルスチェックでは、いくつかの依存サービスも実行されていることも確認する必要がありますか?データベースまたはオーケストレーションシステム自体のように。または、それは別のヘルスチェックの責任ですか? そして最後に、依存サービスの1つが停止し、その後Webアプリが失敗した場合、WebアプリはWebアプリの障害ではないため、健康状態が悪い、または健康状態を報告する必要がありますか? これらは5つの個別の質問であることがわかっていますが、これらはすべて、Webアプリを展開する長期実行サービスのヘルスチェックの範囲に関連しているため、1つの質問にグループ化しておく方が理にかなっていると思いました。 健康なものの定義や、このようなものの標準的な健康チェックがどのように見えるべきかがわからないため、これを実装するのは困難です。 この特定のサービスのヘルスチェックには何を含める必要がありますか?

1
AtomPubをいつ使用する必要がありますか?
私はRESTful Webサービスの設計に関する研究を行ってきましたが、重要な決定点と思われるものに到達したため、アドバイスを得るためにコミュニティに提供すると思いました。 RESTfulアーキテクチャの原則に沿って、発見可能なAPIを提示したいので、さまざまなHTTP動詞を可能な限り完全にサポートします。私の難しさは、これらのリソースの表現の選択にあります。ご覧のとおり、検索結果の表示方法や他のリソースへのリンクの提供方法を​​カバーする独自のAPIを思い付くのは簡単ですが、これは私のアプリケーションに固有のものです。 Atom Publishing Protocol(RFC 5023)、およびODataがその使用を促進する方法について読んだことがありますが、(現在の)かなり単純なAPIに対して抽象化のレベルを追加するようです。 だから私の質問は、開発者が表現の選択としてAtomPubを選択する必要があるのはいつですか?そうでない場合、現在推奨されているアプローチは何ですか?

1
REST Webサービスの認証/アクセス制御のためのソフトウェアアーキテクチャ
新しいRESTful Webサービスを設定していますが、役割ベースのアクセス制御モデルを提供する必要があります。ユーザーがユーザー名とパスワードを入力してサービスにアクセスできるようにするアーキテクチャを作成し、役割に基づいてサービスの使用方法(使用できるサービス、読み取りvs読み取り/書き込みなど)を制限する必要がありますそのユーザーに割り当てられます。 私は他の質問を見て回り、欲しいものを見つけました。たとえば、資格情報をRESTサービスのrestful-authenticationに渡す方法、ベストプラクティスを扱う方法については、いくつかの素晴らしい議論があります。また、プログラマーがWebサイトを作成するときに知っておくべきこと(すべての開発者が公開Webサイトを構築する前に知っておくべきこと)についての優れた指針もあります。 しかし、これらのソリューションを実装するソフトウェアアーキテクチャのベストプラクティスとパターンに関する優れた投稿、記事、書籍を見つけることができませんでした。 具体的には: ユーザーの詳細とアクセス権はどのように保存する必要がありますか?(データモデル、場所、形式) サーバーでこれらを表現および追跡するための優れた設計パターンは何ですか?(メモリ内のセッション、毎回のデータベース検索など) コードベースでこれらの権利を安全な方法でサービスにマッピングするための良いパターンは何ですか? システムをより安全で信頼性の高いものに保つのに役立つアーキテクチャの選択肢は何ですか? トレンチから学んだことは何ですか? 特定の技術以外のソフトウェアアーキテクチャの設計パターンと推奨事項を探しています。 (テクノロジーが重要な場合は、python、twisted、およびpostgresqlデータベースを使用してこれを実装する予定です)

3
非CRUD操作を処理するREST APIを設計する方法は?
SOAPベースのサービスのセットをRESTful APIに変換しようとしています。 オペレーション名を分析してリソースを識別することから始め、リソースを取得しましたSubscription。 サブスクリプションの状態を更新する必要がある場合POST、リソースに直接アクセスできないため、サーバーに単純に要求を送信することはできませんが、RPCスタイルの操作を呼び出してプロパティを更新する必要があります。さらに、サブスクリプションの状態を「アクティブ」に変更する場合にのみ、外部サービスへの追加の呼び出しが必要です。 これらの場合、基礎となる操作を処理するためのベストプラクティスは何ですか? 私が思いついた解決策は、クエリパラメータを使用することです。そのため、アクティベーションサービスを呼び出す必要がある場合は、次のようなものを使用できます。 POST /subscriptions/{subscriptionid}/?activate=true Subscriptionオブジェクトのフィールドを直接更新できないことを考えると、この種の変換を処理するベストプラクティスはありますか? 更新1: POSTリクエストの本文にいくつかの値、たとえば「state」:「active」を入れることができます サービス内でトリガーされる適切な操作を確認します。

7
HTTPS経由の認証はアプリケーションを遅くしますか?
WebアプリケーションとRESTful Webサービスを構築しています。 Webサービスへのリクエストを認証する最良の方法に関するさまざまな記事を読んでいます。 私にとって最良のオプションは、HTTP基本認証を使用することです。私が読んだほとんどすべての記事は、認証はSSLまたは同等のもので暗号化されるべきだと言っています。 私はこれが何を含むのか完全にはわかりません。これは、Webサービス全体が安全なサーバー上にある必要があるということですか?これは遅くなりますか?

4
マイクロサービスアーキテクチャがマイクロサービスごとに個別のデータベースを必要とする場合、コストがかかりすぎて管理できません。なぜそれが必要なのですか?
私はマイクロサービスについて読みましたが、分離を実現するためだけにサービスごとに個別のDBを作成するのは私には非論理的です。Webサービスと単一のデータベースのみを使用して同じことを実現できます。なぜそれが必要なのですか?データベースを分離することは議論の余地があります。または私は明らかに間違っていますか?これについて教えてくれませんか?

3
Firebaseを使用している場合、ビジネスロジックをどこに配置しますか?
マルチユーザードキュメントシステムを非常に簡略化した単一ページのWebアプリケーションの開発を開始します。フロントエンドはおそらくAngular2を使用します。 プロジェクトには短い期限があるため、「ショートカット」、つまりすべてを最初から実装するのではなく、既成のさまざまなサービスを使用することを探していました。 アプリケーションデータを格納するために、なんらかのバックエンドが必要になります。私は周りを見回して、Firebaseを見つけました。Firebaseは、フロントエンドと通信するための個別のバックエンドとAPIを作成する作業の一部を取り除いているようです。 しかし、これはビジネスロジックをフロントエンドのAngular2 Webアプリに配置する必要があることを意味しますよね? では、将来、モバイルアプリのフロントエンドを作成したい場合、ビジネスロジックコードを複製する必要がありますか? ビジネスロジックを含み、データストレージにFirebaseを使用するバックエンドを作成するのが代替策だと思いますが、少し奇妙に思えます(バックエンドでORMまたは何かを直接使用して、もっと多くの仕事?) たとえばFirebaseを利用したい場合、人々は通常どのようにこれらの種類のアプリを構築しますか?

3
エンティティフレームワークエンティティ-Webサービスからのデータ-最高のアーキテクチャ?
現在、いくつかのWebアプリケーションでEntity FrameworkをORMとして使用しています。これまで、すべてのデータが単一のデータベースに格納されているため、これが適しています。リポジトリパターンを使用しており、これらを使用するサービス(ドメインレイヤー)があり、EFエンティティをASP.NET MVCコントローラーに直接返します。 しかし、データベース内のユーザーに関連する追加情報を提供するサードパーティのAPI(Webサービスを介して)を利用する必要が出てきました。ローカルユーザーデータベースに、追加情報を取得するためにAPIに提供できる外部IDを保存します。利用できる情報はかなりありますが、簡単にするために、そのうちの1つはユーザーの会社(名前、マネージャー、部屋、役職、場所など)に関連しています。この情報は、単一の場所で使用されるのではなく、Webアプリ全体のさまざまな場所で使用されます。 だから私の質問は、この情報を入力してアクセスするのに最適な場所はどこですか?さまざまな場所で使用されているため、Webアプリケーションで使用する場合は常にアドホックベースでフェッチすることはあまり意味がありません。そのため、この追加のデータをドメインレイヤーから返すことは理にかなっています。 私の最初の考えは、EFエンティティ(EFUser)を含むラッパーモデルクラス、および新しい情報を含む新しい 'ApiUser'クラスを作成することでした-ユーザーを取得すると、EFUserを取得し、追加のAPIからの情報、およびApiUserオブジェクトを設定します。ただし、これは単一のユーザーを取得する場合は問題ありませんが、複数のユーザーを取得する場合は失敗します。ユーザーのリストを取得するときにAPIをヒットすることはできません。 私の2番目の考えは、ApiUserを返すEFUserエンティティにシングルトンメソッドを追加し、必要なときにそれを設定することでした。必要なときだけアクセスするので、これは上記の問題を解決します。 または、最後の考えは、データベースにデータのローカルコピーを保持し、ユーザーがログインしたときにAPIと同期することでした。これは単なる同期プロセスであるため、最小限の作業であり、ヒットのオーバーヘッドはありません。ユーザー情報を取得するたびにDBとAPIを使用します。ただし、これらはデータを2か所に保存することを意味し、しばらくログインしていないユーザーのデータが古くなっていることも意味します。 このようなシナリオを処理するための最善の方法についてアドバイスや提案はありますか?

1
非同期の内部通信を処理するためのベストプラクティス?
最近、クレジットカード処理を扱うプロジェクトを完了しました。私が直面した問題の1つは、通知メッセージの遅延/起こりうる失敗の処理でした。最も複雑な例は次のとおりです。 支払い要求を送信する外部システム 私のシステムはその要求を支払いゲートウェイへの要求に変えます ユーザーをゲートウェイに送信する ユーザーが支払いを実行するのを待っています ユーザーがシステムに戻ったが、システムが成功/失敗の通知を受け取るまで保留される 失敗に応じてユーザーを外部システムに送り返す さらに困難だったのは、通知の送信に失敗すると、ゲートウェイは15分ごとに何時間も通知を送信しようとすることでした。 保留中のトランザクションのデータベースレコードを使用して解決し、リターンからの成功と失敗に加えて、通知とトランザクション処理のための時限遅延リスナーを検出しました... かなり難しい! しかし、これは何億回も前に解決されたに違いないので、ベストプラクティスは何ですか? 私の将来は、これらすべてのシステム間の処理を記述し、時間遅延と起こりうるネットワーク障害を管理することになるので、ベストプラクティスに従いたいと思います。 本/記事の推奨事項は素晴らしいでしょう。 前もって感謝します!

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.