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

Webアプリケーションとは、インターネットまたは内部ネットワーク（イントラネット）を意味する「Web」を介してアクセスされるアプリケーションです。

5
WebサイトのわかりやすいURLとデータベースIDの現実の提供
製品、ブログ投稿など、リソースのデータベースがあります。パブリックWebサイト用に、それらに対処するURLスキームを設計する必要があります。 データベースIDがバインドされている2つの例を次に示します。 https://www.youtube.com/watch?v=7FPS6llqhXw http://www.amazon.co.uk/gp/product/B000NHOMSQ わかりやすい例は次のとおりです。 http://en.wikipedia.org/wiki/LED_circuit （そこでのブラウジング生活を少し垣間見ます） メールまたはドキュメントでホバーまたは表示するときにURLの末尾に何があるかを知っているので、わかりやすいURLが好きです。SEOの方が良いか、以前はそうでした。 ドキュメントまたは製品の名前が変更されるとどうなりますか？変更された（Wikiは変更されないかもしれませんが、リソースは変更される可能性があります）か、タイプミスのためですか？私たちのリソースは非常に技術的で、長い言葉であり、間違いを起こしやすいものです。 また、数値であるデータベースIDがあります。仮装レンタルストアを使用して、ビデオのアドレスのアイデアを見てみましょう。 http://vidsyeah.com/video/sliding-doors/287171 IDは明らかであり、DBルックアップで使用されます。いいよ スライドドアビットは一意ではなく、ビデオタイトルから生成されただけで、GETで検証できます。したがって、スライドドアが入力され、doc 287171に実際にあるものと一致しない場合、404と応答します。 あるいは、誰かが気にかけた場合、人間が好きなものをそこに貼り付けることができるようにすることもできます。したがって、このURLも機能します。 http://vidsyeah.com/video/anything-at_all/287171 友好的な部分を検証する際の問題は、前述のように、名前の変更またはタイプミスの修正の問題です。名前が変更され、ドメイン内で実際に発生した場合、そこにあるURLを壊したくないので、次のようにします。 友好的な部分を確認しないでください。 確認しますが、以前のフレンドリIDが引き続き機能するように、フレンドリパーツの「履歴」をデータベースレコードに追加します。 あなたの考えやアイデアは大歓迎です。 ルカ
7
公開用のデータベースIDを不明瞭化/難読化することは、本当に「ベストプラクティス」ですか？
私は人々がインターネット上であちこちで講義するのを聞いたことがあります。それはウェブアプリケーションで人前向きのデータベースIDを隠すのがベストプラクティスだということです。私はそれらが主にフォームとURLで意味すると思いますが、私は主題について一口以上を読んだことがありません。 編集：もちろん、今私はこれを尋ねたので、私は主題に関するいくつかのリソースを見つけます： /programming/2374538/obscuring-database-ids /programming/1895685/should-i-obscure-primary-key-values http://joshua.schachter.org/2007/01/autoincrement.html これらのリンクは私の好奇心の一部を満たしましたが、SOの投稿には多くの票がなく、必ずしもこのコンテキストのトピックに集中しているわけではないので、何をすべきかわかりません。リンクは偽です。残りの投稿はそのままにしておきます。 あいまいさとセキュリティの違い、およびこの2つがどのように連携するかを理解していますが、なぜこれが必要なのか想像できません。 これには真実がありますか、それは単なる妄想ですか、それとも完全に偽物ですか？ 私はそれを行う方法を考えることができますが、もちろん、それはアプリケーションコードに多くの複雑さを追加します。これはどのような状況で役立ちますか？これが人々が頻繁に行うことである場合、通常はどのように展開されますか？識別子をハッシュしますか？他に何か？余分なセキュリティを確保するための多くの作業のようです。私は本当の解決策を探しているのではなく、人々が現実の世界でこれをどうやって/なぜ行うのかを知りたいだけです。 これは本当に「ベストプラクティス」と見なされますか、それとも単に価値の低い微最適化のみですか？ 注：少数の人々は間違った考えを持っているかもしれないと思います：推測が困難なIDが唯一のセキュリティメカニズムであることを示唆していません。明らかに通常のアクセスチェックがあるでしょう。それらが適切に配置されており、レコードのIDまたはハッシュされたIDを知るだけでは、アクセスを許可するには不十分であると仮定しましょう。
7
REST APIクライアントとしてのWebアプリケーション：リソース識別子を処理する方法
RESTを実装しようとすると、RESTに関連するいくつかの概念が頭の中で競合します。 ビジネスロジックを保持するRESTフルバックエンドAPIシステムと、UIを提供するWebアプリケーションがあります。RESTに関するさまざまなリソース（特に、REST in Practice：Hypermedia and Systems Architecture）から、エンティティの生の識別子を公開せず、でハイパーリンクを返す必要があることを知っていrel="self"ます。 例を考えてみましょう。REST APIには、人を返すリソースがあります。 <Person> <Links> <Link rel="self" href="http://my.rest.api/api/person/1234"/> </Links> <Pets> <Link rel="pet" href="http://my.rest.api/api/pet/678"/> </Pets> </Person> 問題はWebアプリケーションで発生します。ブラウザへのハイパーリンクを含むページを返すと仮定しましょう： <body class="person"> <p> <a href="http://my.web.app/pet/???????" /> </p> </body> href属性に何を入れるべきですか？ユーザーがターゲットページを開いたときにエンティティを取得できるように、WebアプリケーションにAPIエンティティURLを保持するにはどうすればよいですか？ 要件は矛盾しているようです： ハイパーリンクhrefは、UIをホストするシステムであるため、Webアプリケーションにつながるはずです hrefウェブアプリが対象ページが開いたときに、エンティティに対処することができなければならないので、エンティティのいくつかのIDを持っている必要があります WebアプリはRESTに対応していないため、REST URLを解析/構築しないでください。 URIは消費者に対して不透明でなければなりません。URIの発行者だけが、それを解釈してリソースにマップする方法を知っています。 その1234ため、RESTfulクライアントとしてのように扱う必要があるため、API応答URLから取得することはできませんhttp://my.rest.api/api/AGRIDd~ryPQZ^$RjEL0j。一方、WebアプリにつながるURLを指定する必要があり、アプリが何らかの方法でAPIの元のURLを復元し、そのURLを使用してAPIリソースにアクセスするには十分です。 最も簡単な方法は、おそらくリソースのAPI URLを文字列識別子として使用することです。しかし、そのようなWebページのURL http://my.web.app/person/http%3A%2F%2Fmy.rest.api%2Fapi%2Fperson%2F1234は見苦しいです。 デスクトップアプリや単一ページのjavascriptアプリにとっては、すべて簡単に思えます。彼らは継続的に生きているので、アプリケーションの存続期間中、サービスオブジェクトとともにURLをメモリに保持し、必要なときにそれらを使用することができます。 Webアプリでは、いくつかのアプローチを想像できますが、すべてが奇妙に見えます： API URLのホストを置き換えて、結果のみを保持します。大きな欠点は、APIが生成するURLを処理するためにWebアプリケーションが必要になることです。つまり、巨大な結合を意味します。さらに、私のWebアプリがURLの解釈を開始するため、再びRESTfulではありません。 REST APIで生のIDをリンクとともに公開し、それらを使用してWebアプリのURLを作成し、WebアプリサーバーでIDを使用してAPIで必要なリソースを見つけます。これは優れていますが、Webアプリはブラウザーからの要求を処理するために何らかのフォームのget-by-id要求のチェーンを発行するRESTサービスナビゲーションを通過する必要があるため、Webアプリサーバーのパフォーマンスに影響します。ある程度ネストされたリソースの場合、これにはコストがかかる場合があります。 selfAPIから返されたすべてのURLをWebアプリサーバーの永続的な（DB？）マッピングに保存します。それらのIDを生成し、IDを使用してWebアプリページのURLを構築し、RESTサービスリソースのURLを取得します。つまり、http://my.rest.api/pet/678URLを新しいキー（たとえば3）で保持し、WebページのURLをとして生成しますhttp://my.web.app/pet/3。これは、ある種のHTTPキャッシュ実装のように見えます。理由はわかりませんが、奇妙に思えます。 または、それはすべて、RESTful APIがWebアプリケーションのバックエンドとして機能できないことを意味しますか？
2
フロントエンドで計算を行うのが適切なのはいつですか？
私のチームはWEBベースの財務アプリケーションを開発していますが、同僚と計算をどこで行うべきかという議論が少しありました。純粋にバックエンドで行うのか、それともフロントエンドで行うのですか？ 簡単な説明：フロントエンドにはJava（ZK、Spring）を使用し、バックエンドにはProgress 4glを使用しています。筋金入りの数学とデータベースからのデータを含む計算はバックエンドに保持されるため、私はそれらについて話していません。ユーザーが値Xを入力し、値Yに追加され（画面に表示）、結果がフィールドZに表示される状況について話しています。純粋で単純なjQueryのような操作、つまり。 ここで、ベストプラクティスは次のとおりです。 1）JavaScriptを使用して値を追加し、バックエンドに行ったり戻ったりするのを防ぎ、バックエンドで「保存時」にそれらを検証しますか？ 2）すべてのビジネスロジックを同じ場所に保持します。したがって、値をバックエンドにもたらし、そこで計算を行いますか？ 3）フロントエンドで計算を行います。次に、データをバックエンドに送信し、そこでデータを検証し、計算を再実行します。結果が有効で等しい場合にのみ、ユーザーに表示しますか？ 4）他に何か？ 注：Javaでいくつかの基本的な検証を行いますが、ほとんどは他のすべてのビジネスロジックと同様にバックエンドにあります。 バックエンドのすべてを再計算することで送信されるデータの増加は問題になりません（XMLサイズが小さい。サーバーと帯域幅はユーザーの操作量の増加に耐えます）。
8
クライアント側またはサーバー側の処理を重視する間の長所/短所
多くの処理サーバー側でWebアプリを作成するのはなぜですか？ 私にとって、クライアント側でプログラムを作成することは、最小限の処理でクライアントにデータを送信するだけでよいため、サーバーの負荷を可能な限り軽減できるため、大きな利点です。 サーバー側で記述し、クライアント側をビューとしてのみ扱う以外に、web-appsの記述はほとんどありません。なぜこれをしたいのですか？私が見る唯一の利点は、私が好きな言語で書くことができることです（http://www.paulgraham.com/avg.html）。
1
OAuthの代替手段
Web業界は、APIサービスを外部の消費者と開発者に拡張する際にOAuthを使用する方向に移行/移行しています。シンプルなものにはいくつかの優雅さがあります...そして、3ステップのOAuthプロセスはそれほど悪くはありません...私はそれが最良の選択肢であることに気づきました。 より優れた、より安全な代替手段はありますか？ セキュリティ参照は、次のURLから派生しています。 OAuth 2.0はWebに悪いですか？ Webに悪い署名のないOAuth 2 ITセキュリティスタックエクスチェンジでこれに遭遇しましたが、セキュリティの観点からはそれが痛烈だと思いました。 OAuth / OpenID / Facebook Connect ..クレイジー？ たぶんSAML 2.0が代替手段ですか？ 何についてのOpenIDの？ この質問の目的は、プログラミングの観点からです。 OAuthは今日存在する最良のオプションですか？ セキュリティの観点、実装の観点、長寿命（数か月でやり直す必要はありません）、Webを消費するモバイルアプリケーションのサポートを可能にする消費者にWebアプリケーションを拡張できる代替オプションがありますか応用。
5
RESTfulアーキテクチャの長所と短所[非公開]
閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 5年前に閉鎖されました。 RESTの長所と短所に関して私が見た最も一般的な議論は、SOAPに関連する議論を組み立てる傾向があります。私も経験がありません。私は現在、自分の経験の不足が評価を難しくしている決定に直面しています。私は、いくつかのコンポーネント（主に所有者が複数のサイトを管理できる管理面）と、ユーザーがホストに保持されているデータとやり取りできる公開ユーザーインターフェイスを備えたアプリケーションの開発を始めています。後者の部分をどこでもホストし、RESTfulアーキテクチャを介して前者と通信できるようにすること、または両方のコンポーネントが同じホストに存在することを要求することの意味を評価する必要があります。RESTfulアーキテクチャを開発することの重要な意味は何ですか、特に次の分野での能力に関して： 1：セキュリティ2：パフォーマンス3：インターフェイスの複雑さ 編集：この質問への答えのいくつかを見て-私は明確にする必要があります。SOAPとの比較を探しているのではなく、RESTアプリケーションとすべてのコンポーネントが1つのホストに存在するアプリケーションの概要を探しているわけではありません。（しかし、それらの答えに感謝！）
5
サーバー側のページレンダリングを使用すると、どのような利点が得られますか？
この質問は、Software Engineering Stack Exchangeで回答できるため、Stack Overflowから移行されました。 7年前に移行され ました。 私はWebアプリを開発していますが、現在、Webサイト全体をhtml / js / cssで記述しており、バックエンドにはRESTFULサービスをホストするサーブレットがあります。すべてのプレゼンテーションロジックは、jsonオブジェクトを取得し、javascriptを使用してビューを変更することで実行されます。 アプリケーションは基本的に検索エンジンですが、異なるロールを持つユーザーアカウントがあります。 PlayやSpringなどのフレームワークを研究しています。私はかなりWeb開発に慣れていないので、サーバーサイドページレンダリングを使用するとどのような利点が得られるのだろうかと考えていましたか？ それは：スピードですか？より簡単な開発とワークフロー？既存のライブラリへのアクセス？もっと？上記のすべて？
3
WebアプリケーションでRPCのようなメカニズムの代わりにRESTが一般的に使用されるのはなぜですか？
私はごく最近、少なくとも私が知っている典型的なWebアプリケーションフレームワークと比較して、Webアプリケーションにかなり珍しいカスタムフレームワークを使用している会社で働き始めました。RESTful Webサービスの代わりに、RPCメカニズムを使用してサーバーと通信します。 サーバーとの通信は単純な関数呼び出しのように見えますが、関数はクライアントではなくサーバー上で実行されます。サーバー側には、クライアントが呼び出すことができる機能を定義する方法があります。これをhttpリクエストに変換する方法の詳細は完全に抽象化されています。 私は今これを短い時間だけ使用しましたが、それはかなり便利なようです。しかし、私はこのアプローチのどのような欠点が欠けているのか疑問に思っています。他の誰もが違うやり方をしているように見えますが、これは通常、前者に比べてはるかに高い確率で、私が愚かで素晴らしいことをしているかもしれないというサインです。
5
Java Webアプリケーションのフォルダー構造
J2EEの初心者として、最近、Core of J2EE：Servlets＆Jspsを使用して、ゼロから独自のプロジェクトの開発を開始しました。 プロジェクトのフォルダー構造が正しいかどうかを評価できませんでした。これが私のプロジェクトのフォルダ構造です。 質問をする前に、誰かが私に尋ねたとしても、なぜこのタイプのフォルダー構造なのか、答えることも正当化することもできません。質問：jspをweb-infの外に置くのは良い兆候ですか？そうでない場合、なぜそうなのですか？はいの場合、なぜですか？ J2EE Webアプリケーション用の標準的なフォルダー構造の規則はありますか、mavenがいくつかの標準を導入したことは知っていますが、それでも、要件に応じてカスタマイズできます。 私は少しグーグルをして、2つの参照を見つけました 1 2 答えが同じページになく、そこから結論を引き出すことはできませんでした。 J2EE Webアプリケーションのフォルダ構造をレイアウトする際に考慮すべき点は何ですか、重要なことは、JSP、静的コンテンツをどこに入れるべきか、そしてなぜですか？
4
インターネットでソフトウェアを販売するにはどうすればよいですか？[閉まっている]
閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 6年前に閉鎖されました。 「ネットでソフトウェアを販売したいのですが、Merchantのセットアップ全体をどのように行うのかわかりません。私はCommerce Server 2009にアクセスできますが、プロのようになりたいので、普通の古いPayPalアカウントが公開されています。 ASP.NETを使用していくつかのものを販売したり、クレジットカードを受け入れたりするためには、何を知って/する必要がありますか？
2
GoogleがほとんどのアプリケーションでGWTを使用しないのはなぜですか？[閉まっている]
閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 GoogleはGoogle Web Toolkit（GWT）を作成しましたが、独自のWebアプリケーションを構築する際には使用しません。 これは、GWTが動的アプリケーションの構築に適していないことを意味しますか？または、キャッシュに問題がありますか？またはRPCに問題がありますか？または、Googleがこのテクノロジーを使用できないようにする他の懸念はありますか？ EDIT：ここでは、GoogleがどのアプリでもGWTを使用したことはありませんが、私が言いたいのは、なぜ彼らがGWTを広範囲に使用していないのかということです。
2
複数の小さなアプリを含む大きなAngular 2アプリを作成する
React（with Redux）とAngular 2を選択するための長い3か月にわたる議論と研究の末、私の会社のフロントエンドチームは、Angular 2を採用することを決定しました（私たちの問題により適しています）。 現在、多くの異なるフロントエンドテクノロジーで構成されているエンタープライズアプリビジネスに取り組んでいます（バックエンド全体をRESTfulにしています）。すべてを置き換えて、将来のトレーニングと品質管理を容易にする単一のテクノロジーが必要でした。 私たちの製品の性質を考えると、それは広大であり、その中には異なるドメインであり、スタンドアロンアプリとして作成できるモジュールがありますが、製品自体は単一のURLに存在します。 例; 私の製品をSuperAppと呼びましょう。 UIとして、SuperAppには標準のログインシステムと、子モジュール/サブ製品へのナビゲーションがあり、ワークフローは次のように表示されます。 SuperApp ユーザーを認証する パスワードを忘れたウィザード 認証なしでアクセスできる公開ページ 認証されたユーザー ナビゲーションシステム ホーム サブ製品1 サブ製品2 サブ製品3 プロフィール ... ... グループ ... ... 上記表現にそのノート、Sub-product1そしてSub-product2全く異なるビジネスドメインを有する、2つの全く異なる領域です。 私が今考えることができるのは、自分自身に関連するコンポーネントとビューのみを持つ単一のAngular 2プロジェクトとしてSuperAppを作成でき、SuperAppは複数の子アプリのロードも担当しているということです。Sub-product1、Sub-product2（自分の有する再び、異なる角度の2つのプロジェクトpackage.json、webpack設定、等）をダムコンポーネントを介して、トップレベルのルーティングを提供するシェルと、これらの子アプリを保持するためのプレースホルダとして機能します。 、いったんSub-product1シェル内にロードされ、それがSuperAppがで上陸したことを現在のルートに、独自のルートを追加します。 分離が必要な理由は、これらのさまざまなアプリ（現在はExtJSを使用して構築されている）が専用のチーム（私たちは500人以上の開発者を抱えている会社です）を持っているためです。グランド親アプリに依存せずに好みに依存します。 しかし、公式のAngularドキュメントやWebでは、ネストされたAngularアプリを持つことができるかどうかはまったくわかりません（子アプリの依存関係が完全に分離されてロードされている間にフレームワークコードが共有される方法で）またはそのような問題を解決するための代替アプローチがあるかどうか。 関連する記事へのガイダンスやリンクも歓迎します。
2
リアルタイムの重いWebソケットベースのWebアプリケーションをアーキテクチャ化する方法は？
リアルタイムの単一ページアプリケーションを開発する過程で、ユーザーに最新のデータを提供するためにwebsocketを徐々に採用しています。この段階で、アプリの構造を破壊しすぎていることに気がつき、この現象の解決策を見つけることができませんでした。 詳細に入る前に、ほんの少しのコンテキスト： webappはリアルタイムSPAです。 バックエンドはRuby on Railsにあります。リアルタイムイベントはRubyによってRedisキーにプッシュされ、その後、マイクロノードサーバーがそれをプルバックしてSocket.Ioにプッシュします。 フロントエンドはAngularJSにあり、Nodeのsocket.ioサーバーに直接接続します。 サーバー側では、リアルタイムになる前に、明確なコントローラー/モデルベースのリソース分離があり、それぞれに処理が関連付けられていました。この古典的なMVCの設計は、ユーザーにWebソケットを介してプッシュを開始した直後に、完全に細断された、または少なくともバイパスされました。これで、すべてのアプリが多かれ少なかれ構造化されたデータを流す単一のパイプができました。そして、私はそれがストレスだと感じます。 フロントエンドでの主な懸念は、ビジネスロジックの重複です。ユーザーがページを読み込むとき、古典的なAJAX呼び出しを介してモデルを読み込む必要があります。しかし、リアルタイムのデータフラッディングも処理する必要があり、クライアントサイドモデルの一貫性を維持するために、クライアントサイドのビジネスロジックの多くを複製しています。 いくつかの調査の後、いくつかの特定のトピックを念頭に置いて、現代のWebアプリのアーキテクチャをどのように設計することができ、どのように設計するべきかについてのアドバイスを提供する良い投稿、記事、書籍などは見つかりません： サーバーからユーザーに送信されるデータの構造化方法 「このリソースは更新されたので、AJAX呼び出しでリロードする必要があります」などのイベントのみを送信するか、更新されたデータをプッシュし、初期AJAX呼び出しでロードされた以前のデータを置き換えますか？ 送信されたデータに一貫性のあるスケーラブルなスケルトンを定義する方法は？これはモデル更新メッセージですか、または「blablablablahにエラーがありました」メッセージです バックエンドのどこからでもすべてに関するデータを送信しない方法 サーバー側とクライアント側の両方でビジネスロジックの重複を減らす方法
4
ユーザー定義フィールドを許可するのは悪い習慣ですか？
一般的に言えば、webappのデータベースにユーザーが作成したフィールドを許可することは悪い習慣と見なされますか？ たとえば、妻用のホームインベントリwebappを作成していますが、妻はさまざまなアイテム用に独自のフィールドを定義したいと考えています。私は彼女がアイテムのカテゴリを作成し、それらのカテゴリに「機能」を追加できるようにすることを計画していました。機能は、文字列として保存されたキー/値になります。たとえば、「オーディオCD」というカテゴリがある場合、「アーティスト」、「トラック」などの機能を追加できますが、「家具」などの別のカテゴリでは、「素材」などの機能を追加できます「（木材、プラスチックなど）。次に、任意のアイテムを1つ（または多数）のカテゴリに属し、それらの機能をアイテムに追加します。 これらの機能による検索には文字列の比較が必要であり、データの検証が必要ないなどの問題を見ることができます。アジャイル方法論に従って、新しいカテゴリと属性を考え出すことをお勧めします。私たちが行くように。私の例では、それは小さなユーザーベース（2人）であり、作成されるレコードの量は少ないので、それほど悪くはありません。 しかし一般的に言えば、人々は「現実の生活」でこのようなことをどのように処理しますか？
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.