【ITニュース解説】dev.to's API has no DELETE. It has PUT published:false, which the docs never mention.

APIを利用する際、公式ドキュメントだけでは把握しきれない挙動や、想定外の機能を発見することがある。この記事は、Dev.toというサービスが提供するAPIで、記事の「削除」（正確には非公開化）に関する機能を探索した記録であり、APIを扱うシステムエンジニアにとって重要な学びを提供する。

著者は当初、Dev.toのAPIに記事を削除する機能がないと信じていた。これは、APIのエンドポイントリストを確認した際に「DELETE」という明確な操作が見当たらなかったためである。しかし、その結論が正しいか検証するため、本番環境に影響を与えないよう、まず自分のアカウントで「スクラッチプローブ」（テスト用の仮記事）を作成し、APIの挙動を詳しく調査し始めた。これはシステム開発において非常に重要な、安全な検証の姿勢である。

テスト記事を投稿する際、APIに「公開しない」（published: false）という設定で送信したところ、操作は成功し「201 Created」という成功を示すレスポンスが返ってきた。このレスポンスからは二つの興味深い点が分かった。一つは、非公開の記事には一時的なURLスラッグ（識別子）が割り当てられること。つまり、記事が実際に公開されるまで最終的なURLを知ることはできないため、公開前のリンクチェックのような操作はできない。もう一つは、投稿時に「公開状態」（published）を設定したにもかかわらず、APIの成功レスポンスにはその情報が含まれていなかったことである。これは、APIが送信された全ての情報を必ずしも返さない場合があることを示している。

次に著者は、記事の公開状態を切り替える操作を試みた。既存の記事に対して PUT メソッドを使い、published: true を送ると記事が公開され、URLスラッグも正式なものに変わった。さらに重要な発見として、PUT メソッドで published: false を送ると、記事が非公開状態になることが判明した。この操作後、記事はインターネット上の公開リストからは消え、パブリックページからもアクセスできなくなり「404 Not Found」エラーを返すようになった。しかし、著者の非公開記事リストにはその記事が残っており、内容も失われていなかった。これは、いわゆる「削除」ではなく、「非公開化」という形で記事がインターネット上から見えなくなる操作がAPIで可能であることを意味する。ドキュメントには明記されていなかったが、「記事の更新」という PUT メソッドの本来の目的の範囲内でこの操作が実現されていたのである。

著者は、当初想定していた「DELETE」メソッドを試したが、これも「404 Not Found」というエラーを返した。しかし、この404エラーは、前述の非公開記事アクセス時の404とは異なる意味を持っていた。APIが返すエラーには、通常、その内容を示す「Content-Type」という情報が含まれる。今回のDELETE試行では、エラーレスポンスがJSON形式ではなくHTML形式であった。これは、APIの「このエンドポイントは存在しない」という明確なサインである。一方、非公開記事にアクセスした際の404は、JSON形式の応答、または特定のAPIの挙動として「コンテンツが存在しない、または公開されていない」という意味合いを持つ。同じ「404」というステータスコードでも、レスポンスの「Content-Type」を見ることで、その意味が全く異なることを理解する必要がある。さらに、記事の公開ビューにアクセスする GET /articles/{id} エンドポイントが返す404エラーには、記事が「元々存在しない」「存在するが非公開である」「削除された」という複数の意味が含まれる。API利用者としては、この404だけでは正確な記事の状態を判断できないため、より詳細な情報が必要となる。

このような状況に対応するためには、著者自身が管理する記事リストを提供するエンドポイントを参照することが不可欠である。Dev.toの場合、me/all や me/unpublished といったエンドポイントを使用すると、自身のAPIキーを用いて、自分の記事が実際に存在し、公開されているか非公開であるかを正確に確認できる。つまり、公開ビューのエンドポイントが「404」を返しても、それが必ずしも記事の消滅を意味するわけではない。著者専用のエンドポイントで確認することで、非公開になっているだけでデータは存在するという真の状態を把握できるのである。これは、APIの設計がユーザー（ここでは記事の著者）の視点と一般公開の視点で異なる情報を提供している良い例であり、APIを利用する際には、提供されている全てのエンドポイントとその意味を深く理解しようと努めることが重要である。

非公開化のメカニズムは解明されたものの、著者はさらに踏み込んだ調査を行った結果、非公開にした記事を再び公開するプロセス（再公開）にはまだ問題があることを発見した。具体的には、再公開した記事が、著者のリスト上では「公開済み」と表示されるにもかかわらず、パブリックページや単体記事のエンドポイントからは依然として「404 Not Found」が返ってくるという不整合が発生したのである。この挙動は数分経っても変わらなかったため、現在この「非公開化」操作は、一度行うと安全に元に戻せない可能性を秘めている。したがって、本番環境でこの機能を使用する前に、再公開時の完全な回復パスを完全に理解しておく必要がある。これは、APIが提供する操作の全てが完全に安定しているわけではないことを示唆しており、特に破壊的な可能性のある操作については、十分に検証してから利用を開始するという慎重な姿勢が求められる。

この一連の調査から得られる最も重要な学びは、APIドキュメントに明示されていない機能でも、その本質的な意図を理解し、既存のメソッドを多角的に検証することで新たな発見があるということである。著者は「DELETEがないから削除は不可能」と決めつけてしまったが、実際には「更新」を意味する PUT メソッドの中に、記事の公開状態を操作する機能が含まれていた。APIを利用するシステムエンジニアにとって、ドキュメントに書かれていないからといって不可能だと決めつけるのではなく、既存の機能の組み合わせやパラメータの変更によって、意図した操作が実現できないか深く探求する姿勢が非常に重要である。ステータスコードやレスポンスの形式といった細部の情報にも注意を払い、多角的に検証する探求心こそが、APIを最大限に活用し、予期せぬ問題を解決する鍵となる。