他のフロントエンド開発者と同様に、ほとんどすべてのプロジェクトで、クライアントサーバープロトコルを扱う必要があります。 そして、非常に頻繁に、よく考えられていないアーキテクチャで作業する必要があります。
また、多くの場合、プロトコルとアーキテクチャの開発はWeb開発者に委ねられますが、これは常に真実とは限りません。ほとんどの場合、このアーキテクチャに適応する人のみが開発する必要があります。 残念ながら、過去3年間に数十件のプロジェクトに取り組んでいた私は、このセクションの計画に3〜4回しか参加できませんでした。 しかし、世界はどれほど良くなるでしょう！
エラー処理
ほとんどの場合、私はこのような何かに出くわしました：
HTTP code 200 (OK) <?xml version="1.0" encoding="utf-8"?><Body> <Result> <Success>false</Success> <Error>The username or password is incorrect. Please try again.</Error> </Result> <Response> </Response> </Body>
つまり リクエストの処理結果は最も指定されたXMLに含まれ、HTTPリターンコードは200です。 通常、データは通常のRPCとして表示されます。 たとえば、同様の方法で、SOAPプロトコルのエラー処理は90％のケースで実装されています。
特にヒンドゥー教のコードの特徴である特に高度なケースでは、XMLのさまざまな場所にfalseが存在する可能性があり、解析が大幅に複雑になり、退屈なプログラマーが非常に複雑になり、非常に喜ばれます。
しかし、原則としてこのアプローチの欠点を見てみましょう。
- まず、XMLを解析する必要があります。 これは、ネットワークを介して転送される余分なデータ、XMLの解析に費やされる余分なプロセッサ時間、テキストデータを保存するための余分なRAMです。 Wi-fiゾーンの最新のデバイスではこれはそれほど怖いことではありませんが、アプリケーションのステーション間のメトロでは、同時に何十ものリクエストを送信することで、このような超過が問題になる可能性があります成功）。
- 第二に、ウェブ開発者は自分でエラーテキストを発明しなければなりません。 非常に多くの場合、ユーザーにとって完全に理解不能です。 言葉遣いの正確さは、Web開発者がサービスの作成時に考える最後のことです。 90％のケースのエラーテキストはネイティブスピーカーと一致していません。最後になりますが、最も重要なことは、膨大な数のモバイルアプリケーションをローカライズする必要があることです。 ほとんどの場合、エラーテキストは常に英語でしか書かれていないので、フロントエンドプログラマにとってはまったく役に立ちません。単にそれを拾って出力することはできません。
しかし、Webプログラマーがメッセージのテキストを発明するのにかかった時間は無駄になり、チャンネルには不要な情報がロードされました。
問題を解決する方法は？
HTTPプロトコルは長年、独自のエラーコードを追加できました。これは、512〜597の範囲に属する必要があるためです。このエラー数は、中規模のアプリケーションで発生する可能性のあるすべてのエラーをカバーするのに十分です。 明らかに、これはどのような利点をもたらしますが、それでも要約します：
- 冗長性はありません。 ヘッダー内のHTTPコードのみが送信され、リクエスト本文は単に存在しません。
- クライアント側には、リクエスト処理コードの2つのブランチのみがあります-成功した実行、または実行中のエラー（両方のコールバックは、リクエストライブラリですぐに実装されます）。 「リクエストは成功しましたが、応答本文に論理エラーがある可能性があります」という分岐はありません。
また、HTTP標準と英語版ウィキペディアがこの状況をどのように見ているかを見るのも興味深いでしょう。
5xxサーバーエラー
サーバーは明らかに有効な要求を実行できませんでした[2]
数字の「5」で始まる応答ステータスコードは、サーバーがエラーを検出したか、リクエストを実行できないことをサーバーが認識している場合を示します。 HEADリクエストに応答する場合を除き、サーバーにはエラー状況の説明を含むエンティティを含め、一時的な状態か永続的な状態かを示す必要があります。 同様に、ユーザーエージェントは、含まれているエンティティをユーザーに表示する必要があります。 これらの応答コードは、すべての要求メソッドに適用できます。
つまり クライアントは、サーバーから送信されたメッセージをユーザーに表示する必要があります。 アメリカ人が書いたことは明らかです。 ちなみに、ロシア人は愚かに翻訳されました 。
一般化はしませんが、HTTPコードを使用するというアイデアから、数年前と同じアメリカ人になりました。
一般的に、イデオロギーはこれです-クライアントは常にエラーを報告する方法をよく知っています。 また、サーバーは、最も高速で安価な方法でエラーをクライアントに通知する必要があります。
セッションまたはCookieバインディング。
Webサイトが最初に作成された場合にそのようなリンクが発生する可能性が最も高く、その場合にのみ、顧客はモバイルフロントエンドを作成することにしました。 セッション変数の操作はモバイル側でも可能ですが、これはお勧めできません。 多くの場合、これらのツールを使用するための通常のツールキットはありません。
2番目のグローバルな欠点は、Safari（またはAndroid上の任意のブラウザー）がそのCookieとセッション変数をアプリケーションと共有しないことです。これはもちろん、セキュリティの観点からは正しいですが、多くの問題と松葉杖につながります。
モバイルアプリケーションがWebサイトの機能の70％のみを実装しているとします。 機能の残りの30％はWebでのみ使用でき、アプリケーションには関連するWebページへのリンクのみが含まれます。
これらのページは、許可されたユーザーのみが利用できる可能性もあります。 その結果、すでにモバイルクライアントにログインしているユーザーは、再度ログインするように求められます。今は不快なWebフォームにログインします。ログイン後に、ユーザーがサイトの目的のセクションにリダイレクトされると幸運です。
結論-ユニバーサルプロトコルを設計している場合は、セッション変数やCookieなどを忘れてください。 はるかに優れた方法は、承認中に受信した一意のトークンを、各リクエストの本文で明示的に転送することです。 そして、WebページとWebアプリケーション-単一のAPIの使用に適応します。 すべてのモバイル開発者は、Webアプリケーション用とモバイル用の2つのバージョンのAPIをよく目にします。 しかし、これは機能の重複であり、開発段階とデバッグ段階の両方で常により高価です。 ウェブテクノロジーに近い他の部分に埋め込むよりも、システムの別のレイヤーの特定のポイントからウェブサービスを分離する方が常に優れています。
HTMLリターン
これは、Webサーバー自体の設計にすでにつながります。Webサーバー自体は、元々ブラウザ専用に強化されていました。 エラー403、404、さらにはより複雑な場合は、多くの場合、モバイルアプリケーションで表示する手段を持たないHTMLページの形式で表示されます。 より正確には、資金がありますが、Webビュー内の白い背景に巨大な黒いArial Blackによって「404ページが見つかりません」と表示されると、モバイルユーザーは怖がってアプリケーションを閉じます。
サーバーは、Webサービスへの呼び出しに対してXML（またはJSON）を、最初に合意された形式でのみ提供する必要があることに注意してください。 モバイル開発者は、サーバーから送信されるHTMLを使用して良いことを行うことはできません。
WSDLを使用する
マイクロソフトの技術では、状況はまだ何もありません。最新の技術のほとんどは、そのままでWSDLをサポートしています。 PHPとJavaについては言えません。特にPHP開発者は、基本的にWebサービスである通常のページを手動で作成するのが大好きです。 ただし、WSDL互換のWebサービスと統合するには、モバイル開発者がツールを使用してコードを生成するだけで、Webサービスの手動でコンパイルされた応答も解析する必要があります。
確かに、ここには微妙な点があります-MSとSun（Oracle）の標準WSDL実装にはまだ非互換性がありますが、すべてを手動で書き込むよりもファイルでこれらの非互換性を修正する方が高速です。
おわりに
私は、モバイル開発者が毎日対処しなければならない最も痛みを伴う設計エラーのみに触れました。 記事が需要がある場合、私はあなたが毎日あなたが使用しているWebサービスAPIで私が非常に見たいと思うクライアント・サーバーの微妙な点について間違いなく書きます。