Webを操作する最初のステップは、サーバーアプリケーションにデータを送信することです。 そして、1ダースの小さな行の解析をフレームワークに委ねることができる場合、ファイルのダウンロードはどうですか？
PHPを例にとると、上記は他の言語と技術の99％に当てはまります。 ユーザーがサイトに写真をアップロードできるようにしたいとします。このため、ファイルタイプのフィールドを含むフォームを作成します。 しかし、すべてがそれほど単純ではないので、ファイルが最初に/ tmp /のどこかに収まり、リクエストが完全に到着するまで、スクリプトが制御を取得できず、それについて何もできません。 たとえば、ユーザーは画像の代わりにexeファイルをアップロードしましたが、ダウンロードが最終的に完了した後にのみ、あなたはそれについて知っています。 したがって、攻撃者はしばらくの間、チャネルとディスクサブシステムの時間をhammerし、有用なファイルをロードするふりをすることができます。 キャッシングサーバーがアプリケーションサーバーの前にある場合、状況はさらに悪化します。たとえば、nginxは一時ファイルを作成します。 最初に、ユーザーからのリクエストはディスクに落ち着き、完了するとすぐにファイルが再度読み取られ、すぐにアプリケーションサーバー（この場合はphp）に渡され、再びディスクに保存されます。 ユーザーが「captchaを入力するのを忘れた」というメッセージを表示する必要がある場合でも、ディスクの合計3回の使用。
このアプローチではもっと楽しいことができないという事実については話していない。 「ファイルアップロードの進行状況バー」などの単純な機能は使用できなくなります。 より複雑な例：Youtubeは、まだロードされているが完全にはロードされていないムービーのフレームを表示します。 映画全体（たとえば、2ギガバイト）がダウンロードされる前に、コントロール（および通知さえも）を取得することはできません。 誰かが1.5ギガバイトのディスクを消費したことすら知らないのに、ブラウザを閉じるか、何も待たずにブラウザの更新ボタンをクリックしました。
もちろん、Webサーバーモジュールとして実装された「jsonを介したクエリ統計の取得」などの典型的なタスクを解決できるさまざまな曲率の松葉杖がありますが、そのようなことを自分で行う必要があり、および/またはそれによって環境にアタッチされると、アプリケーションは独立しなくなります特定のアプリケーションとそのライブラリに依存するようになります。
キャッシュ
キャッシュは不可欠です。 キャッシュ技術を使用すると、サイトの応答性を高速化し、サイトの負荷を減らすことができるため、多くのリクエストに対して同じ操作を行う必要がなくなります。 たとえば、2 + 2を行わない数は常に4になりますが、2 + 2を計算するとサーバーリソースが消費されるため、最初の訪問者が到着したときにこの値を1回計算し、他のすべてのユーザーがこれを準備できるようにする方がはるかに有益です結果。
このキャッシングをhttpヘッダーと混同しないでください。サーバー上のキャッシングは、多くのユーザーに同じコンテンツを提供するように設計されていますが、特定のクライアント（中間プロキシでも）にのみ影響します。
残念ながら、ページ上のわずかな更新の場合に中間サーバーにキャッシングを与えることは有益ではありません。ページに多くの動的要素がある場合、実際には各ページが一意であり、一方で、GET / somepage.html？someshit = 12345はキャッシュを突破し、このパラメーターを考慮に入れない新しいページが形成されますが、それでも作成にはコストがかかり、攻撃者が使用できます。 したがって、中間キャッシュサーバーを使用する人はほとんどおらず、それらに依存することは既に非常に困難です。
アプリケーション内のすべてをキャッシュに残し、ほとんどすべてのフレームワークが独自の松葉杖と、あらゆる種類のメモヘッドなどの既製のものを提供します。 通常、初心者の開発者は、ページを生成するときにmemcachedに500件のリクエストを行うことができ、（誰のお気に入りのmysqlとも異なり）memcachedに何も存在しないことを知ったときに沸騰水を書き込むだけです。 その結果、すべてのコードはラッパーで覆われ、最初にmemcacheでリクエストの結果をチェックし、次にmysqlで結果の後に上昇します。 キャッシュを手動で制御する必要があるとは言いませんが、完全に手動で制御するとエラーが発生する可能性があり、キャッシュを有効にするのを忘れてしまう可能性があります。
インターフェース
サイトにはどのインターフェースが必要ですか？ ただその緑を言わないでください。
以前は、原則として、サイトの表示は単一で不可分でした。 ただし、大規模なポータルには、「印刷バージョン」または「スワップバージョン」というボタンがあり、後に「PDAバージョン」に置き換えられました。 場所によって異なりますが、Twitterを使用する場合は、これが唯一の読み取り可能なバージョンです。 時間が経ち、プリンターや携帯電話だけでなく、HTML5をサポートするあらゆる種類のiPadや冷蔵庫のサイトも編集する必要がありました。 当然のことながら、開発者はこれに夢中になりました。実際には、各サイトごとに10バージョンを実行する必要があり、普遍的なことをすることにしました。 サイト用の一種のAPI。
APIとは-わかりません。 正直なところ、わかりません。 通常、これはurlencodeされた文字列でサーバーにつばを吐くとき、ある種のたわごとであり、その見返りにjson / xml /プレーンテキストを取得します。 もちろん、標準、プリミティブデータ型など、何もできません。空の結果は、nullから ""（空の引用符）まで、または結果として存在しないこともあります。 著者がRESTのような単語について読んで、それを実装するために急いだらよいのですが、他のすべての背景に対しては、意味がありません。 機能も明確ではありません。HTMLページをリクエストすることですべてを一度に取得できる場合（最新のニュース、コメント、いいねなど）、APIの場合に必要なリクエストの数-このAPIの作成者のみが知っている、かなり可能ですそのコメントを受け取ることはできますが、好きです-いいえ。 実際、APIは、クライアントとサーバーの開発を、相互に不十分な対話を行う完全に異なる開発チームに分離する方法です。 そして、このAPIの有用性についての話はありません。
また、APIにアクセスするには特定のキーが必要になることがよくあります。 多くの場合、キーは無料で入手できます。 そんな鍵を手に入れてみませんか？ 問題は、これにより、リクエストの明示的なアカウンティング、内部アカウンティングにつながることです。 そして、著者がいつこれらすべてを収益化したいのか誰が知っていますか？ しばらくすると、無料のキーが無効になるか、厳しく制限され、有料の料金を使用できるようになる可能性があります。 また、一般的には、すべてのキーの発行が中断され、サービスが停止します。商業ベースであっても、これも起こります。 さて、なぜAPIなのですか？ このような不名誉に耐えるよりも、ページを伸ばして常連で解析する方が簡単です。 したがって、特にこれらの機能を扱うつもりはないので、これらのAPIをほとんど使用しません。