BbitbbitBook Dev Log #3 — Book Search API Battle: Naver vs. Kakao vs. Aladin

Without Book Data, There's No App

The heart of a reading journal is searching for and registering books.

Manual entry is possible — type the title, author, publisher, cover image URL one by one. But the user experience would be terrible. Nobody wants to do that every time.

Search by title or barcode, select, registered — that's the required experience. Which means a book data API was essential.

Building my own comprehensive book database was not remotely feasible. Open APIs were the only path.

Four Sources Existed

Research turned up four providers offering book search APIs in Korea:

• Naver Book API
• Kakao Book API
• National Library of Korea (도서관 정보나루) API
• Aladin API

All available at no cost. But the data quality and response format differed significantly between them.

Naver vs. Kakao: The Cover Image Problem

In a reading journal, book cover images matter more than expected. The visual representation of your library — covers side by side — is the app's visual identity.

I tested both Naver and Kakao APIs.

Naver: Cover images provided at adequate resolution. Displays clearly at any size in the app.

Kakao: Data quality was acceptable, but cover images were consistently too small. Thumbnail-level images that pixelate when displayed at full size in the app.

Decision: Naver API as default.

Multiple APIs as a Choice

Naver as default, with the other APIs available as alternatives.

When Naver doesn't return results for a specific title, users can switch to Kakao or Aladin. Each API indexes slightly different catalogs — a book missing from one often appears in another.

The National Library of Korea API proved particularly useful for older titles and academic publications.

Fighting with Codable

Each API had a completely different response structure.

The same concept — book title — might be title in one API, bookName in another, titleStatement in a third. Date formats varied. Authors came as arrays in some responses and strings in others.

Swift JSON parsing uses the Codable protocol. Each API needed its own Decodable model, and then those models needed to be converted to the app's internal unified BookItem model.

The chain: Naver API response → NaverBookResponse → BookItem. Repeat for Kakao, Aladin, and the National Library.

Edge cases — missing fields, empty values, unexpected formats — in each API's response took more time to handle than the happy-path parsing.

Data Is Transformed Three Times

API responses don't go directly into Firestore.

The pipeline is:

1. API response → app internal model (parsing + normalization)
2. App internal model → Firestore document (selecting and transforming for storage)

Three representations, clearly separated. Keeping the layers distinct means adding or changing an API later doesn't require touching the rest of the app.

Getting that architecture right early paid off whenever a new API needed to be integrated.