「リアルタイム」の位置データに本当に必要なもの
リアルタイムという言葉は、速いことの同義語として使われています。本来意味すべきなのは、回答が前の四半期のスナップショットではなく、世界の現在の状態を反映していることです。
タグ
#API設計
nullや信頼度の低い結果をどう扱っているか
クエリが本当に信頼できる形で解決できない場合は、事実のように装った推測を返すより、何も返さない方が良い答えです。その選択の背景にある考え方を説明します。
標高データが後回しにされる理由
標高データが料金ページで独立した項目になることはめったにありません。その不在は、それがどれほど真剣に作られているかについて、確かなことを物語っています。
基本的な認証方法に追加料金を課すことへの反論
ヘッダー、Bearerトークン、クエリパラメーターは、どれも同じようにリクエストを認証します。そのうち1つに追加料金を課すのは、機能ではなく好みに料金を課すことです。
プロバイダーを切り替えるときに想定しておくべきレート制限の違い
レート制限は、プロバイダーによって数値だけでなく仕組みも異なります。現在のロジックがそのまま通用すると考える前に確認すべきことを解説します。
誤った推測よりもエラーで答えたい理由
自信ありげに見える誤った回答は、正直な失敗よりも悪いものです。エラーは何かを確認すべきだと教えてくれます。自信ありげな誤った推測は、何も問題がないと思わせてしまいます。
クライアントに手を加えずにサーバー側の連携を移行する
サーバー側のジオコーディングの移行は、多くの場合、それに依存するクライアントアプリケーションからは見えない形で行えます。そのように設計する方法を解説します。
国別の料金体系がよくない考えである理由
ある国の住所の検索に別の国より高い料金を課すことは、地理そのものを、提供すべきごく普通のデータとしてではなく、価格設定の手段として扱うことです。
郵便番号検索を主要な機能として扱うべき理由
おまけのような料金設定とドキュメントの郵便番号エンドポイントは、作り方もおまけのようになります。真剣に扱うことは、同等に扱うことから始まります。
この業界がIPv6の普及についていまだに間違えていること
いまだにIPv6を些細なエッジケースとして扱うIP検索APIは、実際のインターネットトラフィックの増え続ける一部を、気づかないうちに後回しにしています。
アカウント単位とネットワーク単位の割り当てが両方とも必要な理由
アカウント単位の割り当ては、あなたが誰かを追跡します。ネットワーク単位の割り当ては、トラフィックが実際にどこから来ているかを追跡します。まともなシステムには両方が必要です。
すべてのエンドポイントで、よりすっきりしたエラー形式に
すべてのエンドポイントが単一の一貫した形式でエラーを返すようになり、失敗の検出、記録、プログラムによる処理が容易になりました。
Webhook専用のAPIが一括処理のユーザーを知らず知らず締め出す理由
Webhookは、一度に1件のリクエストならうまく機能します。1,000件の検索を送って1,000件の回答を待ちたいだけのスクリプトには、うまく機能しません。
私たちがエラーコードを隠さずに公開する理由
文書化されていないエラーコードは、失敗したリクエストのたびに当て推量を強います。一覧を公開するのは小さなことですが、デバッグの時間を確実に節約します。
一括処理の料金を単一リクエストの料金と同じにすべき理由
1件ずつ送る1,000件の検索と、一括で送る1,000件の検索は、同じ量の作業です。料金は、それがどうまとめられたかによって変わるべきではありません。
退屈で安定したAPIのバージョン管理を支持する理由
話題性のある新しいAPIバージョンは、それを利用するすべての人にとって移行プロジェクトになります。退屈で安定したバージョン管理は、野心の欠如ではなく、1つの機能です。
私たちがブラウザー向けSDKを最初に作らなかった理由
サーバー側の検索のためのブラウザー向けSDKは、たいていAPIキーを訪問者のブラウザーから見える場所に移すだけです。それは持つ価値のある便利さではありません。
ネットワーク単位のレート制限が、キー単位の制限では解決できないことを解決する理由
キー単位の制限だけでは、1つのキーは1人のユーザーだと想定することになります。ネットワーク単位のレート制限は、その想定が知らないうちに崩れる抜け穴をふさぎます。
郵便番号は、今よりもっと尊重されるべきです
郵便番号検索は、ジオコーディングと並ぶとささいなユーティリティとして扱われがちですが、同じように丁寧に扱うに値する、本物の構造と地域ごとの違いを持っています。
ドキュメントの質が機能の数より重要な理由
使い方がわからない機能は、存在しないのと同じです。ドキュメントはサポートのコストではなく、実際の製品の一部です。
ベンダーロックインの見えにくいコスト
ロックインが1つの悪い判断として現れることはめったにありません。それは、そのままとどまるよりも離れるほうがはるかに高くつくように、知らないうちに積み重なる100個の小さな判断として現れます。
レート制限は発見されるものではなく、文書化されるべきもの
本番環境で429エラーを受けてレート制限を知るのは、ドキュメントではありません。本来は発生する必要のなかったサポートチケットです。
一括リクエストを呼び出し単位ではなく項目単位で数える理由
1,000件の住所を含む一括呼び出しでも、1,000件の個別の検索が行われます。それを1リクエストとして数えれば、実際の利用がどこに向かったのかを隠すだけです。
独自のレスポンス形式への反論
独自のフィールド名や独自のオブジェクトモデルは、プロバイダーにとって何の節約にもならず、お客様には後で書き直しのコストを負わせます。平易で予測可能なJSONは、機能の欠如ではありません。
製品ごとの課金がAPIの使われ方について間違えていること
実際のアプリケーションは、1つのリクエストの流れの中でジオコーディング、IP検索、タイムゾーンの呼び出しを組み合わせています。それらを別々の製品として課金するのは、一緒に使われている実態を無視しています。
オープンなタイムゾーンデータをプレミアム機能にすべきではない
タイムゾーンの検索は、公開され活発に維持されているデータソースに基づいています。その検索に別途プレミアム料金を課すことは、実際の追加コストを反映していません。
互換ホストが新しいSDKより重要な理由
SDKは、プロジェクトの存続期間中ずっと1社のクライアントライブラリを信頼することを求めます。互換ホストが求めるのは、設定を1行変えることだけです。
私たちがシート単位ではなくリクエスト単位で料金を設定した理由
リクエスト単位の料金は、APIの実際の運用コストに見合っています。シート単位の料金が測るのは利用量ではなく人数であり、ジオコーディングのトラフィックはそのどちらにもほとんど従いません。