Android 開發者視角：使用 microCMS 建立內容管理系統（CMS）—第 1 天

Hi!

I've been working with Android and cross-platform mobile apps for a while now, and I'm trying to explore other technologies, especially now that AI is basically writing 70 to 80 percent of my code. I miss the days when we used to write code manually...

Anyway, at my day job, a client asked us to add a Content Management System (CMS) to their existing website. They're open to either building one ourselves or using an existing service. Since I'm based in Japan, I decided to study and try a Japanese CMS service called microCMS.

From my research, a CMS is a system for creating and managing content-focused websites like blogs, news sites, and company pages.

A very popular CMS comes to mind: WordPress.

The main difference between WordPress and microCMS is that WordPress is a monolith CMS, while microCMS is a headless CMS. "Headless" means it doesn't have a public-facing frontend. There's an admin screen where you write content, but no website for visitors.

This is the main point of a headless CMS:

CMS stores content and serves JSON; you build the frontend.

Monolith vs Headless, Explained for Mobile Devs

If you've built mobile apps, you already understand headless. You just haven't called it that.

Think about a typical Android project:

• The backend stores data and exposes REST APIs.
• The Android app calls those APIs and draws the UI.

A headless CMS is basically that backend, plus a nice admin dashboard so non-engineers can write content. Your website (or your Android app, or both) is just a client calling the API.

That's why headless is popular. The same content can feed a website, a mobile app, or anything else that speaks HTTP.

Why microCMS?

There are many headless CMS options: Contentful, Strapi, Sanity, and more. I went with microCMS because:

• It's made in Japan, so the docs and admin UI are in Japanese. That matters when the people writing content are Japanese-speaking non-engineers.
• There's a free plan, which is enough to learn and experiment with.
• The admin UI is simple. You don't need to be a developer to write and publish content.
• It's just REST. If you've used Retrofit, you already know how to consume it.

Key Concepts Before We Start

These terms confused me at first, so here's a quick glossary:

If you're a Kotlin dev, the schema is basically this:

data class Blog(
    val id: String,
    val title: String,
    val content: String,   // rich text, returned as HTML
    val eyecatch: Image?,
    val publishedAt: String
)

You're defining that shape, just through a UI instead of code.

Step 1: Create an Account and a Service

1. Go to microcms.io and sign up.
2. Create a new service. You'll choose:
   • Service name: anything, e.g. My Tech Blog
   • Service ID: this becomes your subdomain, e.g. my-tech-blog → my-tech-blog.microcms.io

Your service ID matters because it's part of every API URL.

Step 2: Create Your First API

Inside your service, create a new API. microCMS offers templates (a blog template, for example), but I recommend starting from scratch the first time so you understand every part.

You'll set three things:

Step 3: Define the Schema

This is where you decide what fields a blog post has. Each field has a field ID (used in the JSON), a display name (shown to editors), and a type.

Here's a simple schema to start with:

Other useful field types include date, number, boolean, content reference (link to another API, like a separate "categories" API), and repeater (a list of mixed blocks).

Tip: field IDs are what your code will see, so name them like variables: camelCase, in English, and stable. Renaming one later means updating your frontend too.

Step 4: Write and Publish Some Content

Now switch to the editor role for a moment:

1. Open the Blogs API.
2. Click Add and fill in the title, content, and thumbnail.
3. Click Publish (公開).

You can also save as a draft (下書き). Drafts don't show up in the public API, which is how editors can work on posts without them going live.

This is the moment headless clicked for me. I just wrote a blog post, and there's no website anywhere. The content exists only as data.

Step 5: Call Your API

Each API has an API preview in the admin screen where you can try requests and see your API key. You can also call it from the terminal:

curl "https://my-tech-blog.microcms.io/api/v1/blogs" \
  -H "X-MICROCMS-API-KEY: your-api-key"

You'll get something like this:

{
  "contents": [
    {
      "id": "abc123xyz",
      "createdAt": "2026-11-02T10:00:00.000Z",
      "updatedAt": "2026-11-02T10:05:00.000Z",
      "publishedAt": "2026-11-02T10:05:00.000Z",
      "revisedAt": "2026-11-02T10:05:00.000Z",
      "title": "My first post",
      "content": "<p>Hello from microCMS!</p>",
      "eyecatch": {
        "url": "https://images.microcms-assets.io/...",
        "height": 630,
        "width": 1200
      },
      "category": ["Tech"]
    }
  ],
  "totalCount": 1,
  "offset": 0,
  "limit": 10
}

That's it: a working content API, and I didn't write a single line of backend code.

A few query parameters worth knowing:

To get a single post, add its ID:

GET https://my-tech-blog.microcms.io/api/v1/blogs/abc123xyz

A Note on API Keys

microCMS lets you configure what each API key can do (read, create, update, delete). For anything public-facing, use a read-only key.

As an Android dev, this is the part I'd stress the most: anything you put in an APK can be extracted. A read-only key that exposes only published content is usually fine. Never ship a key with write permissions in a client app.

What I Learned

• A headless CMS is a backend with an admin dashboard. If you've consumed REST APIs in mobile apps, you already know most of what you need.
• Designing the schema is the real work. It's the contract between editors and developers, just like a data class.
• Content lives as data, not pages. That's what lets one CMS feed a website and an app at the same time.

What's Next

Right now I have an API that returns JSON, but nobody can actually see the blog. In the next post, I'll build the frontend with Astro, a framework that turns this JSON into a fast static website.

Thanks for reading! If you're also a mobile dev exploring the web side, let me know what you're learning.