タグ付けされた質問 「client-server」

私が扱ったいくつかのサーバーは、クライアントが失敗と見なすべきリクエストに対してHTTP 200を返します。本文には「success：false」のようなものが含まれます。 これは、特に認証に失敗した場合、HTTPコードの適切な実装とは思えません。「4xx」は変更するまでリクエストを再度行うべきではないことを示し、「5xx」はリクエストが有効または無効であり、再試行できるが失敗したことを示すため、HTTPエラーコードを簡潔に要約しました。この場合、200：ログインに失敗した、または200：そのファイルが見つからなかった、または200：パラメータxが見つからない、間違いが間違っているようです。 一方、「4xx」はリクエストの構造的な問題を示すだけであるという議論が行われていることがわかりました。したがって、200を返すのは適切です。401不正ではなく、不正なユーザー/パスワードは、クライアントが要求を行うことを許可されているためです。この引数は、サーバーが要求を処理して決定を行うことができた場合、応答コードは200である必要があり、詳細については本文を確認するのはクライアント次第であると要約できます。 基本的に、これは好みの問題のようです。しかし、それは満足のいくものではないので、これらのパラダイムのいずれかがより正しい理由が誰かにあるなら、私は知りたいです。

54 http  server  error-handling  client-server 

私が現在理解しているように、HATEOASは基本的に、次に何をすべきかについての情報を各応答リンクと共に送信することに関するものです。簡単な例の1つは、インターネット上で簡単に見つかります：銀行システムとアカウントリソース。この例は、アカウントリソースへのGET要求後のこの応答を示しています GET /account/12345 HTTP/1.1 HTTP/1.1 200 OK <?xml version="1.0"?> <account> <account_number>12345</account_number> <balance currency="usd">100.00</balance> <link rel="deposit" href="/account/12345/deposit" /> <link rel="withdraw" href="/account/12345/withdraw" /> <link rel="transfer" href="/account/12345/transfer" /> <link rel="close" href="/account/12345/close" /> </account> データとともに、次に何ができるかを示すリンクがあります。残高がマイナスの場合、 GET /account/12345 HTTP/1.1 HTTP/1.1 200 OK <?xml version="1.0"?> <account> <account_number>12345</account_number> <balance currency="usd">-25.00</balance> <link rel="deposit" href="/account/12345/deposit" /> </account> 入金のみできるように。Fiddlerを使用している場合、またはブラウザーで要求を行っている場合、何ができるかを簡単に確認できます。この種の情報は、APIの機能を発見するのに役立ち、サーバーはクライアントから切り離されます。 ただし、ポイントは、Javascriptを使用したSPAやAndroidアプリなど、クライアントを構築するときに、HATEOASがどのように関連し続けるかを見ることができないということです。つまり、SPAをJavaScriptでコーディングしている場合、コードを記述するためにAPIで何ができるかを知る必要があります。 …

35 rest  client-server  hateoas 

IPアドレスを介してCookieを使用することでいくつかの追加の利点があることはわかっていますが、私の質問は、クライアントがサイトに再度アクセスしたときにクライアントを識別する際にクライアントのIPアドレスを記憶できないのはなぜですか？コンテナがIPアドレスを使用してクライアントを記憶することは可能ですか？

26 http  session  networks  cookies  client-server 

私は間違いなくそうすべき ケースで100％乗っています、クライアント側とサーバー側の両方のデータ検証使用するます。 しかし、私が働いてきたフレームワークと環境では、私が見たアプローチは決して乾いたことはありませんでした。ほとんどの場合、計画やパターンはありません。検証はモデルの仕様に記述され、検証はビューのフォームに記述されます。（注：私の実際の経験のほとんどは、Rails、Sinatra、およびjQueryを使用したPHPに関するものです） それを熟考すると、検証のセット（モデル名、フィールド、条件など）が与えられると、必要なクライアント側とサーバー側の両方のマテリアルを生成できるジェネレーターを作成することは難しくないようです。あるいは、そのようなツールはサーバー側の検証（たとえば、validates ActiveRecordモデルのコード取得し、クライアント側の検証（フォームに適用されるjQueryプラグインなど）を生成できます。 明らかに、上記は単なる「このアイデアを思いついた」という考えであり、正式な提案ではありません。この種のことは、アイデアが思いついたときよりも確かに難しいです。 それで、データ検証のための「1回だけ書き込み、サーバーとクライアントで実行する」技術の設計にどのようにアプローチしますか？ 関連サブトピック：特定のフレームワークまたはクライアント/サーバーテクノロジーには、そのようなツールが存在しますか？1セットの検証のみを維持しようとする場合の大きな落とし穴や課題は何ですか？

17 design  validation  dry  client-server 

socket.ioを使用して最初のオンラインゲームを作成していますが、agar.ioやdiep.ioのようなリアルタイムのマルチプレイヤーゲームになりたいです。 しかし、すべてのコンピューターを同じ速度で動作させる方法を見つけようとする問題に遭遇しました。 モデルには3つのアイデアがありますが、どれも正しいとは思えません。通常のビデオゲームではどのようにそれが行われるのでしょうか。（私のアイデアを読むことをスキップできます;私が抱えている問題を見る方法を与えてくれます。） サーバーは、クライアントが自分で実行できるようにし、サーバーに更新を渡し、サーバーから残りのクライアントに更新をブロードキャストします。これには、一部のコンピューターが他のコンピューターよりも速く動作し、更新が速くなり、画面上をより速く移動できるという問題があります。 更新するタイミングをサーバーにクライアントに伝えます。次に、最後のクライアントが応答するまで待機し（ある人が遅いコンピューターを使用している場合のひどい考え）、最初のクライアントが応答するまで待機し（再び、各フレームの前に通信を待機します）、またはできるだけ早く送信します（これは、 1）と同じ問題に遭遇するようです。 ゲームの開始時に、サーバーにクライアントに更新の速さを伝えてもらいます。これは、クライアントがその期間の間の移動を制限する責任があることを意味します。たとえば、その期間内に誰かがなんとかボタンを2回押すことができた場合、ボタンを押すイベントは1つしか送信されません。これには、一部のアクション（ダブルボタンを押すなど）が無視され、サーバーのクロックと一致しない可能性のあるクライアントのクロックに相互作用が依存するという問題があります。サーバーは、各クライアントを追跡し、更新が正しい時間に送信されていることを確認する必要があります。 私はいくつかの調査を行いましたが、私が読んだ記事は、クライアントが他のクライアントよりも速く更新を送信した場合の対処方法を具体的に扱っていないようです。 私の特定のケースでは、キーボードの速度が速い人を扱っています（彼らのコンピューターは他のコンピューターよりも多くのキーボード更新を送信します）。 プログラマは通常、これにどのように対処しますか？

15 client-server  real-time 

当社では、組み込みLinuxプラットフォーム上にWebインターフェースを構築する必要があります。2つのオプションがあります：HTMLとJavaScriptがサーバー側で生成されるテクノロジーを使用します（JSP、Grailsを考えますが、C ++を使用してHTML / JavaScriptを生成します）、またはHTML5 'クライアント'を作成しますJSONまたはXML生成バックエンドと通信するアプリケーション。 現在、Webアプリケーションは後者を使用する傾向があると感じていますが、そうすることの利点は何ですか（プロジェクトの開発者は、主にHTMLとJavascriptよりもC ++をよく知っているという事実に基づいて前者を選択します）

13 technology  client-server 

ソフトウェアのアーキテクチャと設計の観点から、マイクロサービスはミドルウェアに対してどのように「積み上げ」られますか（意図されていません）私はJavaから来ています。APIとしてのまっすぐなRESTから離れ、少なくともJavaでさまざまなレイヤーと接続パラメーターを抽象化すると、非常に古い学校のアイデアにほぼ完全に戻ってきたようです。仮想化に戻りました... JVMがすでに仮想化されているかどうか。 不可知論的な方法で、RESTful APIをCORBAに抽象化することができ、その利点を主張します。または、よりJava中心の方法で、JMSまたはMDB。 かつて、EJBはJavaで大きな問題でしたが、それがクラスター効果の一部であると認識されていましたが、今、最初に戻りましたか？ または、マイクロサービスは、CORBA、またはさらに優れたMDBにはないものを提供しますか？マイクロサービスの説明（TLDR）Martin Fowlerを読んだとき、もしそうなら、それは悪い問題の良い解決策として私を驚かせます。むしろ、問題を押し広げるだけの複雑さのレベルをもたらすクローズドマインドアプローチ。サービスが本当にマイクロで数が多い場合、それぞれのサービスの実行と維持に1ドルのコストがかかります。 さらに、多くの中で1つのマイクロサービスがそのAPIを変更すると、そのサービスに依存するすべてが壊れます。それはしないように見えるそれは、疎結合思わアジャイルの反対を。それとも私はそれらの言葉を誤用していますか？ もちろん、これらの両極端の間には不確定な量の選択肢があります。 サメ対ゴリラ...行く！ （知識を深めるために、それは皮肉なことを意味し、私の意図ではありません。質問は額面通りに受け取られることを意味します。質問を改善できる場合は、そうするか、コメントしてください。修正します。 ） Dockerで実行されている多数のマイクロサービスがすべて1台のマシンで実行され、互いに対話していることを想像してください...狂気。保守や管理が難しく、変更を重ねると予期しないエラーが発生するため、何も変更することはほとんど不可能です。これらのサービスが異なるマシンに分散していることはどういうわけですか？そして、それらが分散されている場合、確かに、非常に古くからあるいくつかの手法が、少なくともある程度、分散コンピューティングを解決しています。 なぜ水平スケーリングが普及しているか、少なくとも望ましいのですか？

9 java  enterprise-architecture  distributed-computing  client-server  middleware