ソフトウェア開発にシームレスな体験を提供するというAPI開発者エクスペリエンスは，API設計の改善目標としては比較的新しい視点であるといえる。プログラマの効率向上に寄与すると同時に，開発者がエンドユーザに代わってその目標を達成する上での支援ともなる。
Fitbitのソフトウェアエンジニアで，ユーザエクスペリエンスを重視しているJeremiah Lee Cohick氏は，APIエクスペリエンスの範囲を開発者エクスペリエンス(Developer Experience/DX)の分野にまで拡張して捉えている。このDXの概念は，信頼や教育，ツール，プラットフォームのユーザビリティといった，プログラマと開発プラットフォームのさまざまな関係性も含むものだ。その中でも氏が強調するのは，APIにおけるユーザエクスペリエンス(UX)，すなわちコード記述を中心とした開発サイクルの重要なフェーズとしてのAPIエクスペリエンスである。2014年にWeb Directionsで行ったプレゼンテーションの中で，氏は，優れたAPIが目標とすべき4つの重要事項を指摘した。
- 機能性: どのような問題を，どのようなレベルで解決するか。APIは単に問題の解決に努めるだけでなく，優れた方法で問題を解決しなければならない。
- 信頼性: 可用性，拡張性，安定性といった一連の非機能要件。開発者の使用に値する機能を提供して，信頼の構築を支援する。
- 有用性: APIを選択してその使用方法を学ぶために，API自身がどれほど資するのか(直感性)。開発者がどの程度簡単にテストを作成できるか。エラー処理にはどのようなサポートをしているか。
- 満足感: APIを使うことがどれくらい楽しいか？
Cohick氏の意見によれば，これらの部分がすべて一致したときに優れた開発者エクスペリエンスが実現する。不足や不十分なことがあれば，苦痛や混乱の原因となるのだ。
Intel Mashery(訳注:Intelが買収したAPI管理サービス)で製品リーダを務める，シニアデベロッパでエバンジェリストのAmit Jotwani氏は，“APIに真剣に取り組むのならば，開発者エクスペリエンスを考慮する必要があります”と述べている。氏は優れたAPIの要件として，次の10項目を提案する。
- シンプルであること。
- マーケティング用語(ジャーゴン)の使用を避けて，APIの利用によって不要となるものは何かを明確にすること。
- シンプルかつ迅速なサインアップ。APIキー管理やサービス選択などの簡略化もこれに含まれる。
- セットアップが短時間で可能なこと。５分程度で“Hello World”アプリを作成できなければならない。
- APIキーのプロビジョニングを迅速化し，開発者を長く待たせないこと。
- 費用と制限が明確であること。過剰な期待を持たせない。無償トライアルの提供。
- 充実したドキュメントを提供すること。完全かつ最新として，PDFの使用は避ける。
- Mashery APIエクスプローラやKloutインタラクティブコンソールのようなインタラクティブなドキュメントを提供して，APIの検索と学習を簡単にすること。
- 特定の目的に対してAPIを使用する方法を，コード例を使って明確かつ簡略に示すこと。
- Stack OverflowやTwitterなどのチャネルを利用して，開発者をインスパイアすること。
企業を対象としたAPI改善コンサルタント会社のAPI Academyで，APIデザインディレクタを務めるRonnie Mitra氏によると，APIエクスペリエンスにまず必要なのは開発者も人であるという認識だ。優れたDXを作り上げるためには４つの重要な目標を設定する必要がある，と氏は言う。
- トラブルシュートを容易にする(例えば，適切なエラーメッセージの提供)
- 変更管理をシンプルにする(例えば，APIバージョン管理戦略の実践)
- 視認性を向上する(例えば，ログや使用状況へのアクセス提供)
- 信頼を確立する(例えば，安定性と継続性を持ったコミュニケーション)
ストックホルムで開催されたNordic APIカンファレンスの講演でMitra氏は，Cohick氏と同じように，優れたAPI設計を支援する枠組みと３つの主要な柱 - 機能性，ユーザビリティ，エクスペリエンスを提案した。合わせてユーザビリティの主眼点を，機能性と信頼性のレベルから，開発者を中心としたAPIの利用性へと移している。エクスペリエンスは，機能性とユーザビリティを基盤として構築され，APIやその提供者とのインタラクション全般を開発者がどのように感じるのかに関わっているのだ。
優れたAPIエクスペリエンス提供の鍵はユーザを理解することだ，とMitra氏は言う。これは，APIユーザを一般化したペルソナの定義によって実現される。
誰がAPIを使うのかを知らなければ，ユーザビリティのための設計はできません。
ペルソナを定義すれば，MicrosoftのSteven Clarke氏の研究に基づくことで，APIのユーザビリティ面をさまざまな角度から評価することができるようになる。
-
呼び出し比率: 開発者が望むタスクを達成するために何回のAPIコールが必要か？
-
構造: 必要なデータはどの程度の深さにあるのか？S/N比はどの程度か？
-
ナビゲーション: ひとつの結果から別の部分に移動するのはどの程度難しいか？必要な情報を求めることの難しさはどの程度か？
-
開発者のスタックサイズ: 新しいコンポーネントはいくつ必要か？
-
ファーストコールまでの時間: 新規ユーザが最初のAPIコールを行うまでの時間は？
-
エラー: 修正はどの程度難しいか？エラーの特徴は？(予期せぬ結果，無効な入力，不正シーケンスなど)
同じように，エクスペリエンスを提供するAPIプロバイダの立場からは，関与性，満足感，親密感，信頼性，安全性といったものが，設計プロセスのガイドラインとしてあげられる。これらの側面は，APIのユーザビリティ品質の直接的な産物なのだ。