どうしてみんなAPIについて話していますか?

2515 ワード

JavaScript Ajax httml 5 アプリ

この文章は今よく言われている質問に答えようとしています.なぜみんなAPIについて話していますか.APIの作成方法
サーバとクライアント
10年前、webサーバの仕事はHTMLページを構築し、表現層のクライアントに柔軟ではない表現を提供することだった.Javascriptの役割は、異なるブラウザでラベルを実装することです.
Ajaxリクエストなどの信頼性の高いグラフィックス演算をブラウザで実行でき、Javascriptもますます多くの責任を負っています.
Ajaxは、XMLHttpRequestオブジェクトを使用して、Webページを再ロードせずにウィンドウの一部または一部を更新することができます.ブラウザとサーバ間の通信ロードは完全なHTMLページではありません.ロードされたのは必要な情報だけで、ユーザーがより良いユーザー体験を得ることができ、Webページを動的に見せることができます.
次のように要求します.

POST /users
GET /users/1 #following the redirect
PUT /users/1/enabled

彼らが返すのはHTMLではなくJSONかXMLです.
ガブリエレ・ラナがミラノで先週、HTTPプロトコルに基づくビジネスロジック(サーバ漏れインタフェース)とページプレゼンテーション(クライアントJavascriptディスプレイ)を分離する方法についての議論を聞いたことがあります.サーバが要求を受信してHTMLページを送信するだけで、強制的に2つの階層に分けて実現します.サーバのビジネスロジックとフロントエンドに独立した実装を示し、異なるマシン構成と言語で実装できます.
新しい可能性
Flexを使用してフロントエンドを書き換えるか、Scalaを使用してビジネスロジックを書き換える以外に、(この2つのものの境界が非常にはっきりしているため、彼らを使用してビジネスロジックと表現を明確に区別することができます)、HTTPに基づくいくつかの可能性が実現されています(私はRESTとは言いません):
・新しいフロントエンドを作成できる:まず考えられるのはモバイルWebアプリケーションとモバイルのオリジナルアプリケーションである.ビジネスロジック層は依然として共有されており、異なる言語で異なるUIを実現しているだけです.
・アプリケーションを統合するサービス層は、単純なデータベースインタフェース共有ではなく、各テーブル構造を漏らすのではなく、より厳格なAPIを通じていくつかの操作を分離し、APIベースのアプリケーションを独立させ、データモデルの意外な状況を回避する必要がある.
・APIを使用してアクセスを提供する方法は、他の方法よりも有利である可能性がある.
・アプリケーションが興味深い場合は、サードパーティがアクセスするAPI(有料)を提供することができます.
・オープンデータのアイデアは、APIを通じて政府のデータにアクセスすることであり、公開されたウェブサイトで元の方法で公開される場合は、これらのデータを自分のハードディスクに移行する必要があります.
に挑戦
ブラウザはPUTまたはDELETE要求を実行できないため、ブラウザはGETとPOST要求しか実現できない.この問題は、このような要求が必要な場合、POSTの方法で追加のパラメータを追加し、サーバがこのパラメータを受信したときにPOSTの要求処理を再実現しなければならない.たとえば

POST /users/1/enabled?_method=put

POSTはGETとは異なり、アプリケーションのステータスを変更するという意味ですが、安全ではありません.HTML 5にPUTとDELETEリクエストフォームのサポートが追加されるかどうかはまだ分かりません.
もう一つの問題は、遅延です.HTTPリクエストは一定の最小往復時間を満たさなければなりません.今ではSPDYというものがHTTP遅延を小さくしようとしていますが、複数の異なるAjaxリクエストを初期化して1つのページを構成するのはよくありません.通常、ブラウザは1つのタイムドメイン内で最大6つのリクエストを同時に送信します.幸いなことに、いわゆるHTTPアクセラレータを使用する必要がなく、ページ上のコンテンツをブロックして独立したキャッシュすることができます.
歴史
最後の潜在的な問題は、後退ボタンを良好に動作させる方法など、履歴ページをどのように管理するかです.デフォルトでAjaxリクエストが完了してもアドレスバーのURLは変更されません.これは、戻るボタンを使用して前のページに戻ることができないことを意味します.
現在のHTML 5のHistoryには、ページを再ロードせずに/usersを/users 1に変更できるAPIが用意されています.
古いブラウザでは、新しいページにリンクしてclickイベントをブロックし、Ajaxリクエストをロードし、JavascriptでHistoryを更新するダウングレードカーブの解決策もあります.
まとめ
現在のブラウザの機能に鑑みて、JSONあるいはXML APIをHTTPサーバーの出力終点として使用するのは良い設計であり、また、世界範囲に共通のHTTPベースのAPIがあれば、世界各地のクライアントに同じ業務ロジックにアクセスさせ、クライアント、サーバーは一定のAPI規則に従うだけで、サーバーとクライアントは独立して発展する.テクノロジー、導入、さらには開発言語で利益を得ることができます.
OSchina.NETオリジナル翻訳/原文リンク

jQueryが実装するカスタムPlaceholderプロパティプラグイン

設計案--モバイル端末が300 ms遅延した原因と解決策