国立国会図書館サーチが仕様変更したようなので探ってみる。

読書記録のために個人的に使い続けている自作のfilemakerアプリですが、NDC分類記号が戻ってこなくなったのでなんか変わったのかな、と思いながらも改修せずに放置気味でしたが、思い立って国会図書館サーチの仕様を改めて見てみました。

API仕様の概要 | NDLサーチ | 国立国会図書館

細かい記述は割愛しますがざっと見た感じ、リクエストURLが変わったことがデータを取得できなくなった原因のよう。しかし戻ってくるデータ自体も少し変わっているようなので、これを機に探ってみました。

5種類のインタフェースが用意されている。使えそうなのは3種類の検索と画像API。

国会図書館サーチのAPI仕様の概要（上記リンク先）には、下記のように掲載されてます。この中から今回は「検索用API」の3つを試してみます。
上記リンク先にPDFで配布されてる仕様書を見ながら、細かい技術仕様はよくわからないなりに、とにかくそれぞれのツールでISBN検索をしてみます。

API仕様の概要 国会図書館サーチより抜粋

SRU

記載されてるアクセスURLに、仕様書に従って引数と検索するISBNコードを追加してリクエストURLにします。今回は昨年読んだ中でベスト5に入るであろう、「デザインはどのように世界をつくるのか」です。アクセスURLの末尾に、検索を指示する引数とISBNで検索する旨と検索するISBNコードを付加したものがリクエストURLになります。

https://ndlsearch.ndl.go.jp/api/sru?operation=searchRetrieve&query=isbn=9784845920204

これをsafariなどのブラウザのアドレス欄に入れて表示されるのを見てみます。

なかなかシンプルで最小限のデータが表示されますが、今回探ってみる動機となった、NDC分類に関する記述を見てみると、
<lst name="NDC"> <int name="5">1</int> </lst>
これのみ。分類法の大分類にあたる1桁目のみのようです。

ここで唐突ですが、「取得データのスキーマ」引数を変えてみます。仕様書によると、

設定できる引数は「dc」と「dcndl」があり、省略した場合は「dc」になります。

とありますので、「dcndl」にして再度リクエストしてみます。URLの中に"recordSchema=dcndl"を付け加えてやります。

https://ndlsearch.ndl.go.jp/api/sru?operation=searchRetrieve&recordSchema=dcndl&query=isbn=9784845920204

同様に、ブラウザで表示させてみます。

先と比べると、情報量がとんでもなく多くなりました。（一部分を抜粋しています）書籍に関する情報は前半部分にまとまってるようです。後半部分はよく見ると、各地の県立図書館等の蔵書・配架状況なんかも取得できてることがわかります。

OpenSearch

SRUの場合と同様、記載のアクセスURLにISBNを引数に追加して生成します。こちらはかなりシンプルです。

https://ndlsearch.ndl.go.jp/api/opensearch?isbn=9784845920204

返されるデータの内容はSRUとほぼ同じですが、こちらはかなり整理されてる印象です。これならデータベースに取り込む際のスクリプトも作りやすそうです。

OpenURL

こちらも同様にリクエストURLを生成します。OpenSearchと同様にシンプルです。こちらはHTMLで出力されるので、表示される画面はいわゆるウェブサイトで、国会図書館のサイトで検索結果の画面が返されます。

https://ndlsearch.ndl.go.jp/api/openurl?isbn=9784845920204

いわゆるブラウザに最適化された表示になります。ワンクリックで表示できるので、自動入力でできなかった部分を手作業で補完するのに重宝しそうです。
書誌詳細ページに直接飛べると１クリック分の手間が減るので、その方法があるか調べてみたいです。

書影API

書影を取得するためだけのAPIで、リクエストURLの末尾に13桁ISBNを付加するのみのシンプルな仕様で、リンクではなくjpgの画像データが返されるので、その後データベースに取り込む作業もとてもやりやすいです。2年前の時点では取得できる書籍が少なく、楽天や版元ドットコムを併用していたのですが、現時点ではどうなっているのか、次回調べてみようと思います。

https://ndlsearch.ndl.go.jp/thumbnail/9784845920204.jpg

ここまで、4種類のAPIの検索結果を見てきました。それぞれの目的に応じて利用されてると想像してます。著者が複数の場合、編者や訳者が存在する場合など、それぞれ処理方法が変わってくると思われるので、どれが最適かはやってみないとわかりませんが、私のような零細アプリではOpenSearchを利用して改修していくのが良さそうだと、今のところは感じてます。とりあえず今回はここまで。