APIの5つの段階：2つのバージョンを書くことで実現したこと

今日、私たちは最も内側の話をしたいと思います-APIがあります。



私たちはそれを書き、その後4年間再び書き直しました。 そしてこの間、「避けられないものを受け入れる」というほぼすべての古典的な段階が過ぎました。 1つに加えて-4番目。 そして、私たちは過労によって得られた結論を共有したいと思います。あなたがあなた自身の「強力なエピ」を作ることを決めた場合、何をすべきか、そしてすべきではないか。











uCoz APIを作成するプロセスは、シリーズThe Knick（Knickerbocker Hospital）のプロットに似ていることがあります-失敗した操作、勇気、そして生きている人々の実験。

ステージ1-拒否

一般に、サイト設計者向けのAPIは現在では珍しいものです。 そして2010年には、他の誰もそのような楽器を市場に出していない。



一方で、APIに対する明確なニーズがありました。人々は積極的に「uCozのスクリプト」をグーグルで検索し、直接リクエストを受け取りました。一部のユーザーは独自のアドオンや修正を作成したいと考えました。 一方、これは問題でしたが、当時はすべてのリソースが他のプロジェクトに投入されていました。



「あるかどうか」という質問は、単純に決定されました。 コンストラクタでPHPサポート関数を実行するには、APIが必要でした。 開発者を1人選択し、6か月間「初期API」を作成しました。これは、11モジュールからページデータを受信できる取得専用インターフェイスでした。 データはXMLのみで提供されました。 PHPの予定された発表の時点では、少なくともコンテンツの追加を確立する時間はありませんでしたが、APIにはプラスがありました。それにより、無料バージョンのyukozでPHPスクリプトを実行できました。



一般的に、私たちはユーザーに行きました。 それは古典でまっすぐに判明しました：











彼らは本当に私たちを受け入れませんでした...より正確には、彼らはほとんど私たちを称賛しました。 しかし、PHPの場合。 しかし、「epiai」では、人々はこの魔法の言葉で想像したものを見ませんでした。 技術サポートに質問が寄せられました。「素材を追加するには？ 編集方法 JSONを取得する方法は？」しかし、これだけではありません。

ステージ2-怒り

APIを開発する必要があるという質問に対して、会社は約1年後に戻ってきました。 優先事項はモバイルクライアントでした。iOSおよびAndroidのクライアントを作成した人の要件を考慮して、すべてを書き直すことにしました。 最初のバージョンはそれ自体で生き残った（そして、まだ使用している人もいるのでまだ生きている）ので、新しいプロジェクトのアーティストを選択し始めました。



「あなた自身のマネージャー。」 賢明なイリヤはちょうどロストフのオフィスに来ました。彼は古いuCozの一部が書かれているPerlを知っていました。 問題は、しばらくの間、男が自分のマネージャーにならなければならなかったことです。



それから怒りが来ました。「その過程で判明したように、Perl構文を理解しましたが、精神は理解しませんでした。







だからこそ、私は長い間仕事をしていませんでしたが、世界をやったほうがいいです。すべてを書き直し、オブジェクトクラスパターンを実装することを考えました。 言語のイデオロギーに慣れるのに多くの時間がかかりました。 そして、私が最初に怖いと思い、書き直そうと思ったことは当たり前のように見え始めました。」



啓発の時までに、マネージャーが現れ、報告を要求し始めました。 しかし、それはいくつかのモジュールでコンテンツを配信する準備ができていました...一般的に、今度は再び怒り、イリヤは新しいプロジェクトに移されました。 APIのバージョンは、決して光を見ることはありませんでした。

...ステージ間...

「理想的な学習タスク。」 その時までに、同社はカザンに研究開発オフィスを開設しようとしていました。 代わりに、システム全体に関する知識のキャリアが必要でした。そして、システムのメインモジュールに影響を与えるAPIの作業を通じてそれを「成長」させるというアイデアが生まれました。



したがって、この物語では、Rinatが登場しました。







一方では、彼はプロジェクトに参加することに適度に興奮していました（彼は一般的に少し極端です）。 一方で、彼は冷静で慎重です。それでも、彼は700回以上のパラシュートジャンプだけでなく、ITでの20年の経験も持っています。



彼はPerlにも精通しており、メトリックスとGAをウェブマスターパネルに統合した、外国のAPIを使用した新鮮な経験がありました。



最初に重宝したのは彼の裁量でした。 Rinatは、システムのもつれた「内臓」をより詳細に理解するために休憩を要求しました。それから初めて、条件と実装計画を発表しました。 1か月後、彼は次の提案を思いつきました。



* 純粋にAPIの下でいくつかの機能を書き直し、複製します -システムの作成中に、多くの古いコードがそこに蓄積しました。 そして、いくつかの機能、そこに何か他のものを入れようとした場合、「キロメートル」であることが判明したでしょう。 したがって、純粋にAPIの下でdoubleをクリーニングする必要があります。



* RESTを使用します -リクエストのアーキテクチャを簡素化し、生産性の向上に役立ちます。



* Oauth 1.0a-認証を使用します 。これは当時最も安全であると思われました。



* JSON、XML、テキストプレーン- さまざまな形式で提供します 。



* まあ：取得、投稿、配置、削除、平和、労働、5月...

第三段階-交渉

便利にする方法の一般的な理解に、私たちはやってきました。 しかし、悪魔は詳細と議論にありました。



主な問題はトークンの範囲でした。 Rinatが言うように、私たちのサーバーシステムは「完全にカプセル化されたfigovina」です。N人のユーザーが各サーバーでスピンし、スペースがなくなると新しいハードウェアが使用されます。



Rinatは、1つのトークンを使用してすべてのサイトにアクセスすることを望んでいました。 「さて、それについて話しましょう」と私たちは、Skypeチャットでより多くの同僚を呼びました。 集団チャットで起こるように、彼らは主張し、主張したが、集団決定には至らなかった。 そして、開発の最中に、半分のモジュールの統合の準備ができたときに、トピックは忘れられ、再び浮上しました。











トークンを複製する方法は他にありませんでした。これは、1つのメイン認証サーバーを備えたアーキテクチャが登場する方法です。1つのトークンを受け取った後、どこでも使用できます。



配列またはオブジェクトとしてチェックアウトしますか？ 私たちにとって、これは「正しいこととそうでないこと」というカテゴリーの問題ではありませんでした。 それは細部の問題でした。



たとえば、JSONにデータを送信しますが、型付き言語に問題があります。 APIから受け取ったすべての構造が解析に便利なわけではありません-クライアント側のコード量が増加しているためです。



しかし、APIはWeb迷走に焦点を当てているため、JavaおよびC ++の開発者の意見を聞き、標準に到達しました。いずれの場合でもフィールドを指定し、名前付きパラメーターにコードを追加します。



フィールドとパラメーター。 ここでは、入札と議論が実装のすべての時間に行われました。 たとえば、空のパラメーターを発行する価値はありますか？ APIを使用したモバイル開発にも焦点を当てたため、Rinatはそのプロセスにおいて、それが不要であることを証明しました。モバイルアプリケーションではトラフィックが重要です。



そして、どのフィールドが必要ですか？ ここで、プロジェクトマネージャーである私にとっては、実際の実践から事例を検索して提示する必要がありました。 多くの場合、私は聴衆の助けを借りて、将来のAPIユーザーにインタビューしました。 送信されたサードパーティの開発者の事例が価値があると思われる場合は、必要なフィールドをAPI自体に実装して、松葉杖の後に人々がそれを行わないようにしました。 その後、彼らはよりエレガントなソリューションを思いつきました。それについては以下で説明します。

第4段階-...（およびタイミング）

その年に計画された作業には、ほぼ2時間がかかりました。 その過程で、まったく予期していなかった困難がありました。 私たちはすぐに気付きました：











2番目の開発者の問題。 計画によると、Rinatが承認を行った後、2番目の開発者はAPIとモジュールの統合に接続することになっています。



モジュールをアルファベット順に並べてGoogle Dockをペイントしました。 それらの作業は、パフォーマーの間で半分に分割されました。 スケジュールを決定しました-各月に1つのモジュール。 開始する時間になると、2人目の男性が立ち去りました。 そして、私たちはすでに新しいプロジェクト-uKitコンストラクターを作成し、その上に主要なリソースを投入しました。 2人目のプログラマが失われたため、実装期間にほぼ7か月が追加されました。



テストの問題。 理論的には、プロセスは次のように考えられていました。開発者のサーバーの後、すべてがアルファサーバーに進み、テスターが「続行」と言うと、ベータテストに合格し、更新は数百のサーバーに分散されます。



しかし、通常のテスターはAPIの操作にはあまり適していないことが判明しました。結局のところ、彼らはWebページをテストするために「シャープ」になっています。 APIは微妙なものです。 たとえば、統合したモジュール内で変更があった場合、何かが落ちる可能性がありますが、テスターは最初はこれに気づきませんでした（その後、それらを教えました）。



次に、4つのテストサーバーを開き、初期段階で上級ユーザーを招待しました。 このような群衆は、したがって、あまり制御されていません（人がいつ何かをやめ、やめないかはわかりません）、テストも用語の増加に影響しました。

第5段階-謙虚さ（および結論）

最終的に、避けられないものに対処しました-APIは、修復と同様に開始できますが、簡単に終了することはできません。 ここでは、プロセスを整理して簡単にするためのいくつかのレシピを示します。



1.フィードバックを取得します。 より多くの接続。



フォーラムのスレッドとブログの投稿に加えて、つまり コメントを交換するための公開手段として、新しいドキュメントを使用してサイトの「実験室」セクションを開始しました。 実際には、個人的なやり取りでケースについて議論できるフィードバックフォームでした。



2015年2月に初期のユーザーに新しいAPIについて通知し、すべてのモジュールをサーバーに展開するプロセスは今年だけ完了しました。 この間ずっと、ユーザーから「研究室」レポート、オファー、興味深いケースを通じてレポートを受け取りました（Rinatとの「オークション」でも使用しました）。





申請の流れは過去2か月でのみ減少しました



「これをどのように行うか、ここで何をするか」というアピールを受けるたびに、時間を割いて座って見に行きましたが、何が良いでしょうか？ 時々面白い話がこれから生まれました。



2.理解していない人や[贈り物としてのスクリプト]を個人的に助けます。



以前は、ラボからのメッセージが非常に面白かったので、スクリプトを自分で書き始めました。 そして、完成したソリューションをユーザーに提示し、



利益はいくらですか？ sayingにもあるように、「バグを見つけたい場合は、バグになりましょう」。 そして、あなたがプロジェクトに没頭したい場合-パフォーマンスと利便性をチェックするために、できる限りそれをしてください。 同時に、uAPIを使用した最初のソリューションがuScript交換に登場しました。ソーシャルネットワークを介した承認と、推奨される素材のブロックでの写真の不正確な出力です。



3.内部ハッカソンを実行します。



覚えているように、テスターがいませんでした。 そのため、製品をテストするための内部ハッカソンのアイデアが生まれました。 一部の開発者にとって、APIの操作はまったく新しい珍しいタスクであったため、さまざまなスキルを持つ人々の行動を綿密に観察する機会がありました。





Rinatは通常、ユーザーと直接通信しませんでしたが、KazanからRostov開発者へのハッカソンに来ました。 「トローリングを除いて、収集されたデータと批判のプロセスに満足しました。」





4.何かを自動化してみてください。



APIを操作するための私のお気に入りの機能は、アプリケーションとトークンの半自動作成でした。







当初、このシステムは私の個人的なニーズから生まれました-ある時点で、アプリケーションを作成するときにリクエストに署名するのに時間を浪費するのに疲れていました。 それから、私は半自動モードを書くことにしました-何も考えないように、データをコピーしました-アプリケーションは準備ができています。 判明したように、今ではほとんどの人が半自動ソリューションを使用しています。



5.ドキュメントを参照して変更します。



最初に、PHPとCURLでサンプルリクエストをペイントしました。









そうだった。 結局のところ、CURLを使用した人はいませんでした。



しかし、人々は、たとえば、どのような形式で、どのようにリクエストを送信するかを尋ねました。 最初の実装は誰にとっても明らかではないことが明らかになりました。



oauthの署名が自動的に生成される追加モジュール（最新のOOPで記述された）が必要であると判断しました。 このモジュールを呼び出したら-パスとリクエストメソッドを記述します。



並行して、プログラマーを調べて、質問しました。どのAPIのAPIが価値のあるロールモデルであると考えていますか 推奨される例を見て、それらに基づいて、新しいバージョンのドキュメントをコンパイルしました。











また、公開前のテストとして、2番目のオフィスの同僚に、APIがすべてのメソッドのドキュメントの説明に従って動作することを確認するよう依頼しました。



6.モビリティを実装します。



まず、良いレビューを得て視聴者を拡大するのに役立ちます：

サイト用のモバイルアプリケーションを作成することは長い間夢でした。 私は最終的にそれを実現するためにuAPIを勉強します

第二に、社内チームにとって貴重で新しい経験となります。 たとえば、ハッカソンで、私たちの何人かがそのようなアプリケーションを見送りました。





ここで 、アプリケーションコードを見ることができます



7.ユーザーの欲求を制限しないでください。



フィールドの問題に戻りましょう。 すべてのケースを予測するわけではないため、最後に、このトピックに関する大胆な空想を実装できるクエリコンストラクターを作成しました。







最後に、APIは双方向の動きであるという結論に達しました。 現在、uAPIを使用して、任意のサイトの認証、uCozからの材料の転送、およびその逆を行うことができます。データベースのみを使用しますが、サードパーティのサイトにデータを表示します。 ツールに選択するユーザーケースが多いほど、実装は長くなります。 しかし、同時にその適用範囲は拡大しています。





PS



新しいバージョンの展開と戦闘テストの全プロセスには、14か月と20の更新が必要でした。 これが視覚化です。



次の更新後、「いつ終了しますか？」という書き込みが発生することがありますが、プロセスを停止するのは非常に困難です（修復について冗談は言いませんでした）。 時々-技術的な理由から：システムの更新がAPIの変更を必要とする場合を考えてみましょう。 そして、時には創造的です。 たとえば、モジュールとのすべての統合が終了したら、APIによってデザインとサイトの設定を変更するトピックを解決してみませんか？