内部プライベートAPIを「公開」することは、パブリックAPI候補を作成し、内部で使用し、満足したら公開するというベストプラクティスと比較して、悪い考えであると管理者(製品管理など)に説得する必要があります。誰かが私が議論をするのを助ける研究論文のようないくつかの事実を見つけるのを手伝ってくれる?
1 に答える
APIへのパブリックインターフェイスは非常に主観的であり、特に問題のドメインに関連付けられているため、特定の調査については知りません。
このPDFの最初の数ページは、ビジネスパーソン向けのAPIの概要です。http: //aarontgrogg.com/wp-content/uploads/2009/09/How-to-Build-API-and-why-it -matters.pdf
このブログ投稿セクションヘッダーは、あなたがすでに知っていると思うので、あなたのビジネスパートナーが考える必要がある重要なポイントを強調しています。パブリックAPIに関連するこれらの特定の主題に関するベストプラクティスを検索します:http://gaejexperiments.wordpress.com/2010/07/01/public-api-design-factors/
- API形式のRESTとWebサービス
- 応答形式XML、JSON
- サービス契約の説明
- APIのコンシューマーのための認証メカニズム
- サービスのバージョン管理(全員を爆破することなくAPIの新しいバージョンをロールアウトできるようにするため)
- レート制限(明らかに、DOS攻撃を防ぎ、システム負荷を管理するだけで、さまざまなことについて)
- ドキュメンテーション
- ヘルパーライブラリ
- パブリックAPIのWebサイト
- APIの種類によって異なります...サポートチーム
これは、内部プロセスにも対応していません。内部システムは、パブリックAPIよりも速く進化できる必要がありますか?あなたの会社はビジネスモデルと戦略に機敏に対応したいと考えているので、ほとんどの場合、答えはイエスだと思います。サードパーティに内部システムを消費させると、更新を行うときに誰がより重要であるかを会社が決定する必要があります。あなたの会社は、その内部サービスをバージョン管理して、サードパーティの消費者がタイムリーにアップグレードすることを期待するか、すべてのサードパーティの消費者の統合を破る必要があります。
結局のところ、それは行う価値がないかもしれません。APIを使用している人は、使用をやめる前に何度も失敗するだけです。誰も使わないのなら、なんて良いことでしょう。
私は以前、ビジネスがAPIのプッシュを速すぎて、その周りにガバナンスがないことを望んでいた立場にありました。その結果、私たちのAPIと統合している人々をサポートし、彼らのためにコードサンプルを作成することにすべての時間が費やされました。