ハイライト
Activity内の任意のrequestをクリックすると、フルペイロードが表示されるようになりました。もう一度クリックするだけで、Playgroundで事前入力された状態で再度開き、すぐに再実行できます。また、送信したrequestを偽のresponseとしてそのままエコーバックする一部のproxyを検出し、データが汚染されるのを防ぐ仕組みを導入しました。
新機能
Activity → Playground: 任意のrequestをリプレイ
すべてのAPIコールは、X-Foura-Request-Id headerを返します。Activity内のrequestの横にも同じIDが表示されます。任意の行をクリックすると、実行日時、使用されたキー、request body、response、ステータスコード、所要時間など、詳細な情報を確認できます。「Open in Playground」をクリックすると、requestがフォームに事前入力された状態でロードされます。
これまで、リプレイとは記憶を頼りにrequestを再構築することを意味していました。これからはActivityが履歴を保持し、Playgroundが再実行ボタンの役割を果たします。
知っておくべきいくつかの仕様があります。APIキーごとに直近200件のペイロードを24時間保持します。それ以降は、新しいエントリーが入るにつれて古いエントリーから削除されます。ペイロードの保持期間が過ぎた場合、以前のように紛らわしいnullや「(empty body)」を表示するのではなく、ダイアログでその旨を通知するようになりました。
request IDを関連付けることも可能です。クライアント側で独自のrequest IDと並べてX-Foura-Request-Id response headerをログに記録しておけば、後から一致するActivityの行をコピー・アンド・ペーストするだけで簡単に見つけられます。
キャプチャ処理はホットパス（主要な処理経路）の外で行われます。そのため、API requestがこの処理を待つことはありません。また、キャプチャストアにアクセスできない場合でもコールは通常通り実行され、後からダイアログに「no body captured」と表示されるだけです。
response bodyに対する検証
Playground's Validateセクションに、bodyコンテンツのルールが追加されました。「responseにXが含まれている場合のみ成功」、または「Yが含まれている場合は失敗」といったルールを指定でき、複数の候補を|で区切ることも可能です。SingleおよびProxyで動作します。ステータスコードが実際の処理結果と異なる場合に便利です。
bodyのないペイロードの明確化
失敗したrequestには、表示するresponse bodyがありません。以前のダイアログではこれをnullや「(empty body)」と表示していたため、実際に空のresponseが返ってきたと誤解しがちでした。現在、ダイアログは次の3つのケースを区別して表示します。requestが失敗した（実際のエラーメッセージを表示）、ペイロードがキャプチャされなかった、またはサーバーが実際に0バイトを返した。
細かい変更ですが、「今のは実際のresponseなのか、それともUIのバグなのか」と迷うことがなくなります。
PlaygroundのResetボタン
ワンクリックで、アクティブなendpointのフォームをデフォルト状態に戻します。ユースケースの9割をカバーするため、デフォルトではunblockerとtryJsonDataがオンのまま維持されます。
舞台裏
ハニーポットproxyの検出
世の中の一部の「proxy」は、実際には転送を行いません。これらは、送信されたrequestをプレーンテキストのサーバー変数ダンプ（HTTPメソッド、header、ターゲットホスト）としてそのままエコーバックし、運営者がその中身を収集できるようにしています。単一のセッション内で、同じproxyが1つのrequestを転送し、次のrequestをエコーバックし、その次のrequestで502エラーを返すという挙動を確認しています。
現在、bodyバリデータはresponseがエッジを離れる前に、このダンプのシグネチャを検出します。Singleは正確なエラーを返します。Proxy Finderは別のproxyで再試行します。Browserも、共有HTTPレイヤーから同じ防御機能を引き継ぎます。これにより、Activityに表示される不要な行が減り、スクレイパーが一見データのように見えて実際にはただの調査（プローブ）であるものを誤って取り込むのを防ぐことができます。
現時点では、レピュテーションの変更は行っていません。当面の間、そのproxyはプール内に維持されます。単に、その虚偽のレスポンスをユーザーに返すのを拒否するだけです。
したがって、以前は一見「成功」のように見えていたrequestが、Activityで明確なエラーとして記録されるようになった場合、それはこの防御機能が作動したことを意味します。汚染されたレコードを取り込むよりも、明確に失敗する方がはるかに安全です。