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

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

1
ASP.NETで適切なサービスレイヤーを構築する方法
私はいくつかの質問、優れたサービス層を構築するための技術を調べてきましたが、これに関して私が助けを必要とするいくつかの質問があります。 最初に、私が要件について持っているもののいくつかの情報。現在、スパイダーウェブのような方法で相互に通信する多くのWebアプリケーションがあります(すべて、Webサービスとデータベースデータを介して、混乱する方法で相互に通信します)。 これを変更して、すべてのアプリケーションがサービスレイヤーを通過するようにしたいと思います。サービスレイヤーでは、キャッシュを使用して作業し、共通の機能などをカプセル化できます。 サードパーティのクライアントがサービスからの情報を利用できるように、このレイヤーにもWeb APIが必要です。 問題は、たとえばMVC4 Web APIでサービスレイヤーを構築する場合、webAPIを使用してアプリケーション間で通信する必要がないということです。つまり、URLを構築してJSON / Xmlを消費する必要があります。それはあまり効果的に聞こえません。エンティティとWCFを使用してアプリケーション間の通信を行う方が良い方法だと思いますが、Web APIの魔法を失う可能性がありますか? したがって、問題は、サービス層をWeb API(JSON / XML)とエンティティを含むよりバックエンドのサービス層の両方として利用する方法があるかどうかです。2つの異なるサービスレイヤーを使用せざるを得ない場合、一部の機能や他の悪いことを複製する必要があるかもしれません。 質問が十分に明確であることを願って、さらに情報が必要かどうか尋ねてください。

2
再帰的なリソースに最適なRESTful URL構造は何ですか?
ツリーのようなリソース構造用のRESTfullサービスを作成していて、最適なURL構造は何だろうと思っていましたか? 私には3つの要件があります。 ルートリソースのコレクションを取得できる 個別のリソースを取得できる 子リソースのコレクションを取得できる 私の現在の考えは: /rest/documents /rest/documents/{id} /rest/documents/{id}/documents 単数/複数のルートを使用してリストまたは個々の要素を示すことも考えていましたが、単数と同じ複数のリソースを使用することになるので、これに対して決定しました。 上記について何か考えはありますか?またはこれを構造化する別の/より良い方法がありますか?

7
これは「アンチパターン」であり、使用を中止すべきですか、それともこの巧妙な設計ですか?
RESTサービスを作成するとき、私は基本的に次のことをするために凝視しました: HTMLが要求されています サービスは必要なWebページを返しますが、要求された「リソース」はありません。データ Webページには、同じサービス(異なるコンテンツタイプ)にAJAXリクエストを発行するJavaScriptが含まれています サービスが実際のデータ(JSON)を返し、ページに表示されます 一方では効率が悪いように見えます(2リクエスト)が、これを使用した場合、「パフォーマンスは問題ありません」、つまりトラフィックの少ない内部アプリとWebサイトはシンプルで高速にロードされます。 私がこれで終わった理由は、Webページがほとんど純粋なHtml + JavaScriptになる可能性があり、そのようなテーブルやものを作成するためにサーバー側のもの、特にループがほとんど必要ないことです(これは、 slickgridなど)、たとえばデータとビューの分離。 これを使用する前に、これは良いアイデアですか、それともやめるべきですか?

6
真の乱数ジェネレーターWebサービスが必要[終了]
閉まっている。この質問はトピックから外れています。現在、回答を受け付けていません。 この質問を改善してみませんか? 質問を更新して、ソフトウェアエンジニアリングスタック交換のトピックになるようにします。 5年前休業。 Random.orgは、アナログの世界(cf.)からIPごとに1日あたり200kのランダムビット(32ビット整数は6250のみ!)を提供します。 誰かが1日あたりのオンデマンドのランダムビット数を増やす代替のWebサービスを知っていますか? (価格が1000×1024ビット/米ドルセントの「予想内」である限り、支払いは問題ありません)(random.orgの有料サービス料金100×この価格)

2
マイクロサービスと正規モデル
このサイトでマイクロサービスについて読んでいたときに、以下のステートメントに出くわしました。正規スキーマとはどういう意味ですか?ドメインモデルと同じではありませんか? マイクロサービスアーキテクチャパターンは、正規スキーマの概念など、SOAの他の部分も拒否します。

3
CRUD API:更新するフィールドをどのように指定しますか?
ある種のデータベースに永続化されているある種のデータ構造があるとします。簡単にするために、このデータ構造を呼びましょうPerson。これで、他のアプリケーションがを作成、読み取り、更新、および削除できるようにするCRUD APIを設計する必要がありますPerson。簡単にするために、このAPIが何らかのWebサービスを介してアクセスされると仮定します。 CRUDのC、R、Dパーツのデザインはシンプルです。私はC#のような関数表記を使用します-実装はSOAP、REST / JSON、またはその他の可能性があります。 class Person { string Name; DateTime? DateOfBirth; ... } Identifier CreatePerson(Person); Person GetPerson(Identifier); void DeletePerson(Identifier); アップデートはどうですか?自然なことは void UpdatePerson(Identifier, Person); しかし、どのフィールドを更新するかをどのように指定しますPersonか? 私が思いつくことができる解決策: 常に完全な Personを渡すように要求することができます。つまり、クライアントは次のようにして生年月日を更新します。 p = GetPerson(id); p.DateOfBirth = ...; UpdatePerson(id, p); ただし、そのためには、GetとUpdateの間にトランザクションの整合性またはロックが必要になります。そうしないと、他のクライアントによって並行して行われた他の変更を上書きする可能性があります。これにより、APIがさらに複雑になります。さらに、次の疑似コード(JSONをサポートするクライアント言語を想定)であるため、エラーが発生しやすくなります。 UpdatePerson(id, { "DateOfBirth": "2015-01-01" }); -これは正しいように見えます-DateOfBirthを変更するだけでなく、他のすべてのフィールドをnullにリセットします。 であるすべてのフィールドを無視できますnull。しかし、それを変更しないこと DateOfBirthと、意図的にnullに変更することの違いをどのように作成しますか? 署名をに変更しますvoid UpdatePerson(Identifier, Person, ListOfFieldNamesToUpdate)。 署名をに変更しますvoid …

2
RESTまたは多層異種システムのメッセージキュー?
Client application-> Front-end API cloud server->のような3層システム用のREST APIを設計していますuser's home API server (Home)。 Homeはホームデバイスであり、Front-endWebsocketまたは長い投票(これは、RESTに違反している最初の場所です。後でさらに悪化します)を介した接続を維持することになっています。Front-endほとんどの場合、Client要求をHome接続にトンネルし、一部の呼び出し自体を処理します。にHome通知を送信することがありますClient。 Front-endHome基本的に同じAPI を持っています。LAN経由で直接Client接続している可能性がありますHome。この場合、それ自体にHomeいくつかのClientアクションを登録する必要がありFront-endます。 このシステムでのRESTの長所は次のとおりです。 RESTは人間が読める形式です。 RESTには、動詞(CRUDなど)、名詞、および応答コードのプロトコルオブジェクトへの明確に定義されたマッピングがあります。 HTTP上で動作し、可能なすべてのプロキシを渡します。 RESTコントラは次のとおりです。 リクエストとレスポンスのコミュニケーションスタイルだけでなく、パブリッシュサブスクライブも必要です。 3層通信エラーを処理するには、HTTPエラーコードでは不十分な場合があります。必要な接続が壊れていて、あるはずだったことを知るためだけに、非同期呼び出しにFront-end戻る場合があります。202 AcceptedHome503 Homeにメッセージを送信する必要がありますClient。ClientポーリングするFront-endか、接続を維持する必要があります。 我々は考えているWAMP / アウトバーンを、それがすでにメッセージキューのように見ていることを私を襲ったとき、機能をパブリッシュ/サブスクライブを取得するのWebSocketの上に。 一種のメッセージングキューをトランスポートとして評価する価値はありますか? メッセージキューの逆のように見えます: CRUD動詞とエラーコードをメッセージレベルで自分で定義する必要があります。 「メンテナンスコストが高い」と書いてありますが、どういう意味ですか? これらの考慮事項はどのくらい深刻ですか?

5
適切なWebサーバー開発セットアップのアドバイス[終了]
休業。この質問には、より焦点を当てる必要があります。現在、回答を受け付けていません。 この質問を改善してみませんか?質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てます。 6年前休業。 1か月ほど前に、私は最初のLAMPスタックを作成し、その頭字語の各文字を実行する単純なWebサイトを実装しました。しかし、私の開発設定は理想的とは言えませんでした。私は実際にはローカルのテストサーバーを持っていませんが、代わりにすべてのCGIスクリプトをvimで書き込んでいて、リモートマシンにrootとしてsshを実行していました。今、もっと真剣な開発を始めたいと思います。 質問:開発をできるだけ簡単に行うための適切な設定とは何ですか? IDE、サブバージョン(または代替)、コンテンツのアップロードとダウンロード、およびベストプラクティスに沿って利用できるものを理解したいと思います。私はこれでかなり新しいです。また、良いウェブサイトを私に向けてください。ウェブサイトはたくさんありますが、既にウェブコンテンツを開発している人だけが、自分が良いウェブサイトかどうかをすばやく判断できます。

1
べき等のWebサービス呼び出しを実装する方法
私は、「時々接続された」モバイルデバイスが使用するWebサービスレイヤー用のWCFベースのソリューションを開発しています。追加の複雑さのため、サービスは(この段階では)キューイングを使用しないため、単純な要求/応答アプローチを操作します。 もちろん、モバイルデバイスであるため、挿入/更新中にデバイスが信号を失う可能性があります。Webサービス自体がトランザクションを完了した可能性がありますが、クライアントはこのメッセージを受信しません。このため、サーバーは要求を再送信します。その時点で、サーバーはこれを重複要求として認識し、最初のインスタンスで試行したのと同じ応答を返す必要があります。 したがって、私はサービスをべき等にすることを試みています。これを実現するために、RequestIDと、呼び出しを完了するために必要なパラメーターで構成されるRequest Paramter DTOオブジェクトを実装しています。 ただし、リクエストIDを監視する方法を実装するのは難しいです。サービスは現在ステートレスであるため、現在想定できる唯一の方法は、データベースにServiceRequestテーブルを作成することです。これにより、RequestIDがプライマリになります。これを照会すると、クライアントが同じRequestIDを送信するため、要求がすでに処理されているかどうかがわかります。ただし、サービスはどのメッセージを返信するかを知る必要もあります。挿入/更新の場合、影響を受ける集約ルートIDも、リクエストテーブルに直接、またはRequestToObjectLookupテーブルに直接格納する必要があります。 それで、これを実装するためのベストプラクティスの方法があるかどうか疑問に思っていますか?私の考えは、リクエストID、追加情報、および結果オブジェクトIDへの参照(保存/挿入/更新)を格納するServiceRequestテーブル(サービスに固有)を用意することです。そのため、新しいリクエストが来たときに、保存を実行するか、または以前に更新されたオブジェクト(最初のリクエストの試行で実行されたオブジェクト)を返すだけかを問わず、残りのリクエストに進む前にこのテーブルを最初に参照できます。 (述べたように)残りの情報を取得するために関係を使用できるようにする必要があるため、リクエストで参照されるルート集約IDのみを保持する必要があると私は考えています。

1
複数のAPI、または「chooser」パラメーターを持つ1つのAPI?
データソースの上にビジネスロジックを追加するWebサービスがあるとします。このサービスの各APIはほとんどのように見えます-一連の制約が与えられた場合、これらの制約を満たすデータソースからのアイテムを提供します。APIからデータソースの「ビュー」を取得したと言えます。 ここで、時間の経過とともに、データソースに対してさまざまな種類のビューを返すように求められます。「十分に異なる」ビューごとに新しいAPIを追加するか、ギアを切り替えて、目的のビューの種類を指定するパラメーターを取得するgetFooDataView()APIを提供するオプションがあります。どちらの方法に行くかを決定するために、いくつかの競争圧力があります。 あなたのサービスの既存の大きなクライアントは怠惰であることを好み、データの新しいビューが必要なときに新しいAPIまでコーディングする必要はありません。 ただし、一部のリクエストパラメータ(制約)は一部のビューでのみ意味があり、他のビューでは意味がありません。「XYZビューが必要な場合は、 "foo"パラメータを設定すると、APIコントラクトを緩くする必要があります。一部のビューではそうであるとしても、 "foo"を必須パラメーターにすることができないという残念な副作用があります。 新しいクライアントがサービスを活用したいというケースはますます増えています。どちらがより混乱するかを決定することはできません-異なるがより厳密に定義されたAPIと、パラメーターのどの組み合わせが本当に必要なものを提供するかを知る必要がある1つのAPIを選択する必要があります。 これを抽出するために、既存のAPIのバリエーションとは対照的に、何かが独自のAPIである必要があるという線を描くのはいつですか?2人のクライアントの要求を意味的に区別する理由については、協力しなければならない人によって見方が異なるため、この問題についてコンセンサスを得るのは難しい場合があります。また、将来のクライアントがサービスを利用するのが極端に難しくならないようにする必要もあります。この種の選択を行うためのいくつかのベストプラクティスは何ですか?

2
このソリューションはRESTfulで安全ですか?
私たちの製品は私たちのサービスに新しいプレーヤーを登録し、それをAzure(私たちは.NETを使用しています)でホストすることを選択しました。 これは私が書いている最初のREST WSであるため、それが確実な解決策であるかどうかについてフィードバックを得たいと思いました。 アプリについて知っておくべきいくつかの仮定: ユーザーは、ユーザーのパスワードを要求せずに、匿名でサービスにログインします 水平スケーリングを可能にするには、WSは完全にステートレスである必要があります サードパーティのスヌーピングを防ぐためにHTTPS(SSL)を使用して接続しています 編集: ネイティブiOS / Androidデバイスを対象としています 私たちの主な懸念は、改ざんされていないクライアントのみがリクエストを送信できるようにすることです そして抽象的な認証プロセス: クライアントは単純なハッシュ(UDID:Timestamp)を作成し、タイムスタンプを使用して基本的なアルゴリズムで暗号化します(たとえば、秘密鍵はハッシュの2番目の文字ごとです) クライアントはサーバーにUDID、タイムスタンプ、ハッシュを送信します サーバーはハッシュを再構築し、ユーザーから送信された暗号化されたハッシュを復号化します 2つが等しい場合-実際にクライアントから送信されたことがわかります(悪意のある送信者からではないことを願っています) すべての入力/提案は素晴らしいでしょう-明らかに私がこの問題を処理しているのは初めてなので、私はそれを間違って設計したかもしれません。 ありがとう! 2回目の更新: OAuthのセキュリティ仕様を読むと、クライアントとサーバーは秘密鍵を知っている必要があり、クライアントはユーザーのモバイルデバイス(ウェブアプリではなく)にローカルに保存されているため、私の質問に対する実際の回答はないようです。 OAuthセキュリティガイド(http://hueniverse.com/oauth/guide/security/)から: OAuthを実装する場合、対称または非対称の共有シークレットの制限を理解することが重要です。クライアントシークレット(またはプライベートキー)は、サーバーがクライアントの身元を確認するために使用されます。WebサーバーなどのWebベースのクライアントの場合、クライアントの秘密(または秘密鍵)の機密を保持することは比較的簡単です。 ただし、クライアントがデスクトップアプリケーション、モバイルアプリケーション、またはブラウザーアプレット(Flash、Java、Silverlight)やスクリプト(JavaScript)などの他のクライアント側ソフトウェアである場合、クライアントの資格情報をアプリケーションの各コピーに含める必要があります。 。これは、クライアントシークレット(またはプライベートキー)がアプリケーションと共に配布される必要があることを意味し、継承によってセキュリティが侵害されます。 これは、そのようなアプリケーション内でのOAuthの使用を妨げませんが、サーバーがそのようなパブリックシークレットで持つことができる信頼の量を制限します。シークレットは信頼できないため、サーバーはそのようなアプリケーションを不明なエンティティとして扱い、アプリケーションに関する統計の収集など、信頼のレベルを必要としないアクティビティに対してのみクライアントIDを使用する必要があります。一部のサーバーは、このようなアプリケーションを禁止したり、さまざまなプロトコルや拡張機能を提供したりすることがあります。ただし、現時点では、この制限に対する既知の解決策はありません。

6
1時間ごとにコードを実行する[終了]
閉まっている。この質問はトピックから外れています。現在、回答を受け付けていません。 この質問を改善してみませんか? 質問を更新して、ソフトウェアエンジニアリングスタック交換のトピックになるようにします。 4年前休業。 1時間ごとに実行されるWebサービスを作成する必要があります。これは、データベース内のデータを確認し、特定の条件が満たされている/満たされていない場合に同じデータベース内のテーブルにアラートを追加するために使用されます。私たちが現在持っているものは: Pythonを使用してAmazon Web Services(AWS)仮想サーバーにレポートするエンドデバイスがあります。AWSサーバーはその情報を取得してMySQLデータベースに保存します。AWSサーバーはDjangoとApacheを実行するLinuxです。エンドデバイスによって保存されたデータを検証するPythonコードを毎時間実行できるようにする必要があります。特定の条件が満たされない場合alerts、データベースのテーブルにレコードが追加されます。 上記の設定を作成することを最初に契約しました。Python、Django、Apacheは初めてです。ただし、エンドデバイスとの間でデータを送受信するPythonコードにはすでにいくつかの変更を加えています。私はWebプログラミングに侵入しているコーダーです。 誰か私がこれを行う方法について何かアドバイスはありますか?

3
単体テストをすべきか
私のWebサービスのロジックのほとんどは、サプライヤーのWebサービスとの対話(可用性の確認、注文など)を含みます。それらにはテスト環境がなく、ほとんどの呼び出しは任意に実行できません(たとえば、停止は1回実行され、実際にサービスを停止します)。 この環境で単体テストを実行することは可能ですか?一般的な応答をシミュレートすることはできますが、サプライヤの応答をハードコーディングすると単体テストのポイントが損なわれるのではないかと心配しています。

2
RESTサービスの一意のリクエストIDのHTTP応答ヘッダー
RESTサービスでは、すべての応答で一意のリクエストIDを送り返したいと思います。内部プロジェクトのデバッグに役立つだけでなく、将来サービスを使用する可能性のあるサードパーティにサポートを提供する場合にも役立ちます。 すべてのRESTリクエストがレスポンスボディになる必要があるわけではないため(多くの場合、低レベルのREST APIはステータスコードと説明のみを利用します)、このリクエストを送り返す必要があるため、レスポンスヘッダーを使用する必要があると判断しました。 ID。 可能であれば、途中でプロキシによって取り除かれる可能性が低い HTTP応答ヘッダーを使用するようにします。 多数のクライアントがモバイルデバイスであり、クライアントとサーバー間の「興味深い」ネットワークトポロジにバインドされているため、これは非常に重要です。 ただし、同じサービスが、自社のファイアウォール/プロキシを使用する他の企業にも販売される可能性があります。 このため、よく知られているヘッダーの代わりにカスタム応答ヘッダーを使用するという考えを根本的に覆いました。 私の現在の優勝既知のヘッダーはETagヘッダーですが、それはほぼ正しいですが、それは完全ではありません- ETagはリソース用であり、リクエストではありません(つまり、同じリソースに対する2つの別々のリクエストは合法的に同じを返しますETag)。さらに、それを使用すると、エンティティタグを他の目的で実行できないことを意味します。 誰か良いアイデアはありますか? 更新 Pragmaヘッダーは使用されているように見えますが、Asp.Net WebAPI内での書き込みに問題があります。 SOに関する関連質問です。

2
ライブビデオストリーミングサービスを作成するにはどのようなテクノロジーが必要ですか?[閉まっている]
休業。この質問には、より焦点を当てる必要があります。現在、回答を受け付けていません。 この質問を改善してみませんか?質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てます。 5年前休業。 私は、stageit.comやlivestream.comなどのサービスを作成するためにどのようなテクノロジーが必要かについて興味があります。放送局のコンピューターから視聴者のコンピューターまで、カメラとマイク以外にどのようなハードウェアとソフトウェアが関係していますか?

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