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

WebサービスとWeb APIについてよく耳にしましたが、それらに違いはありますか、それとも同じですか？

84 web-development  terminology  api  web-services 

特に、ユーザーがWeb APIで許可/認証された操作を実行する方法に興味があります。 認証CookieはRESTの哲学と互換性がありますか？

77 web-applications  web-services  rest 

3層（DAL、BL、UI）でアプリの構築を開始しました[主にCRM、いくつかの販売レポート、在庫を処理します]。 同僚から、サービスレイヤーパターンに移行する必要があり、開発者が経験からサービスパターンにアクセスするようになったと言われました。彼は、将来そのようにアプリケーションを維持する方がはるかに簡単になるだろうと言いました。 個人的に、私はそれが物事をより複雑にしているだけだと感じており、それを正当化するような利益はあまり見られませんでした。 このアプリには、デスクトップアプリケーションの機能の一部（ただしごくわずか）を使用する小さな部分UIが追加されているため、コードを（あまり多くは）複製していません。いくつかのコードの重複のために、私はそれをサービス指向に変換しませんが、一般的にそれは非常に優れたアーキテクチャであるため、とにかくそれを使用するべきだと言いました。 私はそれでグーグルしようとしましたが、私はまだ混乱しており、何をすべきかを決めることができません。

68 design-patterns  architecture  web-services  services  service 

最近、マイクロサービスアーキテクチャに関する次の優れた記事を読みました。http：//www.infoq.com/articles/microservices-intro AmazonにWebページをロードすると、100以上のマイクロサービスが協力してそのページを提供することが記載されています。 その記事では、マイクロサービス間のすべての通信はAPIを介してのみ行うことができると説明しています。私の質問は、すべてのデータベースの書き込みはAPIを介してのみ可能であると言うのがなぜ悪いのかということですが、さまざまなマイクロサービスのデータベースから直接読み取ることができます。たとえば、マイクロサービスの外部からアクセスできるデータベースビューはごくわずかであるため、マイクロサービスを管理するチームは、これらのビューをそのまま保持している限り、マイクロサービスのデータベース構造を変更できることを知ることができます。欲しいです。 ここに何かが足りませんか？API経由でのみデータを読み取る必要がある他の理由はありますか？ 言うまでもなく、私の会社はAmazonよりもずっと小さく（常にそうです）、私たちが持つことのできるユーザーの最大数は約500万人です。

64 architecture  web-services  soa  microservices  modularization 

Youtubeを例として使用したいと思います。彼らはの形式のIDを使用しますPEckzwggd78。 単純な整数を使用しないのはなぜですか？ またはimgur.com- 9b6tMZS画像やギャラリーなどのIDも使用します。連続した整数ではありません。 なぜ整数（特に連続した整数）を使用しないのですか？ どのような場合、整数の代わりにそのような文字列IDを使用することが賢明な決定ですか？

54 database  database-design  web-services 

外部APIから入力を受け取る関数をコーディングしているとしましょうMyAPI。 その外部APIにMyAPIは、a stringまたはa を返すことを示す契約がありnumberます。 それはのようなものから保護することをお勧めしますnull、undefined、booleanそれはのAPIの一部ではないにもかかわらずなど、MyAPI？特に、そのAPIを制御することはできないため、静的型分析などの方法で保証することはできません。 私はロバストネスの原則に関連して考えています。

51 design  api  api-design  web-services  functions 

最後に、SOAPベースのサービスに出くわしたのは、2013年に金融会社でインターンシップを行っていたときです。それが、ITでのキャリアを始めたときでした。私のエンジニアリングコースの1つで、SOAPについての学習資料を持っていたことを覚えています。それ以外では、私はキャリアの中でSOAPをあまり使用していません。 「SOAPとRESTの違い」という質問が最近のインタビューの1つで出てきたので、私はこれを尋ねています。私が知っていること（およびGoogleで発見したこと）から、SOAPは、ビジネスロジックに密接に関連する情報交換のためにクライアントとサーバーを密結合したプロトコルです。一方、RESTはデータ転送のためのより柔軟なステートレスアーキテクチャです。 SOAPとRESTのこの違いについて間違っている場合、誰かが私を修正してくれますか？また、SOAPの現在の重要性は何ですか？人々はまだ新しいSOAPベースのAPIを開発していますか、それとも今はほとんどレガシーですか？

51 rest  api  web-services  soap 

RESTサービスの仕様をまとめています。RESTサービスの一部には、サービス全体およびリソースのグループまたは個々のリソースでユーザーを調整する機能が組み込まれています。同様に、これらのタイムアウトは、リソース/グループ/サービスごとに構成できます。 HTTP 1.1仕様を調べて、クライアントが制限に達したために要求が満たされないことをクライアントに伝える方法を決定しようとしています。 最初は、クライアントコード403 - Forbiddenが1つであると考えましたが、これは仕様からです。 承認は役に立たず、リクエストは繰り返されるべきではありません 私を悩ませた。 実際に503 - Service Unavailableは、使用するほうが良いようです- Retry-Afterヘッダーを使用することで再試行時間の通信が可能になるためです。 将来的には、eコマースを介してより多くのリクエストを「購入」することをサポートする可能性があります（この場合、クライアントコード402 - Payment Requiredが確定されていればいいと思います！）。 私はどちらを使うべきだと思いますか？または、私が考慮していない別のものがありますか？

43 web-services  rest  http 

RESTful APIの設計を進めています。特定のリソースに対してJSONとXMLを返したいことがわかっています。私はこのようなことをすると思っていました。 GET /api/something?param1=value1 Accept: application/xml (or application/json) ただし、次のように、誰かがこのために拡張機能を使用して投げ出しました： GET /api/something.xml?parm1=value1 (or /api/something.json?param1=value1) これらのアプローチのトレードオフは何ですか？拡張機能が指定されていない場合はacceptヘッダーに依存するのが最善ですが、指定されている場合は拡張機能を優先しますか？そのアプローチには欠点がありますか？

40 architecture  web-services  rest  http 

Steve VinoskiによるREST、Reuse、Serendipityに関するこの講演を見た後、（XML-）RPC-ishセットアップのグリーンフィールドプロジェクトにRESTがより良い方法で解決できなかったビジネスケースがあるのではないかと思います。 彼が言及したいくつかのRPC問題： 言語に焦点を当てる（分散システムをその言語に適合させ、その逆ではない） 「ローカルに見えるようにする」（およびルールではなく例外として障害と遅延に対処する） 言語に依存しないことを意図しているが、依然として主要な成分として言語間で「関数呼び出し」を持っている IDLボイラープレート 型の安全性の錯覚 そして、さらにいくつか... 少しドラマ化するために、RPC vs RESTのGoogleインスタント結果をいくつか示します。

33 web-services  rest  use-case  rpc 

リソースベースのサイト（MVCアプリケーションやRESTサービスなど）で作業する場合、クライアントGETがアクセスできないリソースをクライアントが試行する場合、主に2つのオプションがあります。 403、クライアントが無許可であると言う; または 404は、リソースが存在しない（または見つからなかった）ことを示します。 一般的な知恵と慣習は真実で応答することであるようです-つまり、403。しかし、私はこれが実際に正しいことかどうか疑問に思っています。 安全なログインシステムは、ログイン失敗の理由を決して知らせません。つまり、クライアントに関する限り、存在しないユーザー名と誤ったパスワードの間に検出可能な違いはありません。これの目的は、ユーザーID（またはさらに悪いことに、電子メールアドレス）を検出できないようにすることです。 プライバシーの観点からは、どのリソース誰かが伝えを見て、リアリティショー（サバイバーが、私は思う）の受賞者を出した前記私は事件を思い出してる404を返すように多くの方が安全と思われるしなかっ上に存在しますサイトvs. 403がシリアル番号やアカウント番号などの機密情報を提供する可能性があることを心配しています。 404を返さない説得力のある理由はありますか？404ポリシーは他の場所でマイナスの副作用を引き起こす可能性がありますか？そうでない場合、その慣行はより一般的ではないのはなぜですか？

33 web-development  web-applications  security  web-services  privacy 

私は、ユーザーがサーバーに対して任意の信頼できないpythonコード（このようなビット）を実行できるようにする必要があるプロジェクトを持っています。私はpythonにかなり慣れていないため、システムにセキュリティホールやその他の脆弱性を招くようなミスを避けたいと思います。利用可能なベストプラクティス、推奨される読書、または私のサービスを使用可能にするが悪用できないようにする他のポインターはありますか？ これまで私が考えてきたことは次のとおりです。 コンテキストから削除__builtins__して、execなどの潜在的に危険なパッケージの使用を禁止しますos。ユーザーは、私が提供したパッケージのみを使用できます。 スレッドを使用して、適切なタイムアウトを強制します。 execコンテキスト内で割り当てることができるメモリの総量を制限したいのですが、それが可能かどうかはわかりません。 ストレートexecに代わるものがいくつかありますが、ここでどれが役立つかわかりません： を使用して、ast.NodeVisitor安全でないオブジェクトにアクセスする試みをキャッチします。しかし、どのオブジェクトを禁止する必要がありますか？ 入力内の二重アンダースコアを検索します。（上記のオプションよりも優雅ではありません）。 PyPyコードのサンドボックスを使用するか、サンドボックスに似たもの。 注： JavaScriptベースのインタープリターが少なくとも1つあることは承知しています。私のシナリオではうまくいきません。

31 python  security  web-services 

SOAPの消費にはSOAPスタックが必要であることがわかります。したがって、クライアントは消費するのが難しくなります。つまり、POSTデータとヘッダーを正しくフォーマットしてから、データ構造ですが、RESTではクエリ文字列の引数を使用してHTTP GETリクエストを作成し、おそらくXMLであると思われるテキストを取得します。 それでは、SOAPの余分なオーバーヘッド/複雑さは何をあなたに与えますか、いつそれを必要としますか？

30 web-services  rest  soap 

私の仕事のために、私たちが持っているいくつかのウェブサイトを動かすために使用する素敵なRESTfulウェブサービスがあります。基本的に、Webサービスを使用すると、サポートチケットを作成および操作でき、Webサイトがフロントエンドを担当します。Webサービスリクエストでは、認証ヘッダーを使用します。このヘッダーを使用して、呼び出しごとにユーザーとパスワードを検証します。 今年は、Webサイト上のユーザーがGoogle、Twitter、Facebook（おそらく他のユーザー）経由でログインできるように、ログインオプションを拡張することを検討しています。ただし、Webサービスがサードパーティの認証プロバイダーを使用して、ユーザーが本人であることを確認できるように、これをどのように設計するかについて多くの問題を抱えています。これを行うためのベストプラクティスはありますか？ 現在、Webサイトでユーザー自身の認証を処理してから、現在のセッションをWebサービスバックエンドに登録する新しいsetSessionId呼び出しを使用することを考えています。Webサービスへの追加の各リクエストは、そのセッションIDを渡し、検証します。これらは大丈夫のように見えますが、私はこれを考えていないという私の頭の後ろの感覚を持っています、そして私のすべてのフォーラムの閲覧とoauthとopenidの仕様を読んでいるだけでもっと混乱させられます。これに取り組む方法のヒントはありますか？

25 web-services  rest  authentication  oauth  openid 

システム間で（ビジネスレベルで）APIについて議論するとき、チームには2つの異なる視点があります。一般的な抽象アプローチを好む人もいれば、そうでない人もいます。 例：単純な「個人検索」APIの設計。具体的なバージョンは searchPerson(String name, boolean soundEx, String firstName, boolean soundEx, String dateOfBirth) 具体的なバージョンを支持する人々は言う： APIは自己文書化されています わかりやすい 検証は簡単です（コンパイラーまたはWebサービスとして：スキーマ検証） キッス 私たちのチームの他のグループは、「これは単なる検索条件のリストです」と言うでしょう。 searchPerson(List<SearchCriteria> criteria) と SearchCritera { String parameter, String value, Map<String, String> options } おそらくいくつかの列挙型の「パラメータ」を作成します。 支持者は言う： API（の宣言）を変更することなく、実装は変更できます。たとえば、基準やオプションを追加します。展開時にそのような変更を同期しなくても。 具体的なバリアントでもドキュメントが必要です スキーマ検証は過大評価されており、多くの場合、さらに検証する必要があります。スキーマはすべてのケースを処理できません 別のシステムと同様のAPIが既にあります-再利用 反論は 有効なパラメーターと有効なパラメーターの組み合わせに関する多くのドキュメント 他のチームにとって理解するのがより難しいので、より多くのコミュニケーション努力 ベストプラクティスはありますか？文献？

25 api  web-services  api-design