Toni MaxxToni Maxx

How the Lean REST Namespace in NativePress Works

By Toni Maxx · Published · 4 min read

wordpress api

  • Built with
  • WordPress
  • PHP
  • React
  • Expo

A native app does not need a web page. It needs the content of a post. The default WordPress REST output sends much more than that. This note shows the difference in plain words, and why NativePress serves a lean version instead.

What the default output carries

WordPress has a REST API built in. For a post it sends many fields: dates in two formats, a slug, a status, link lists, comment settings and more. The title, the excerpt and the body arrive as HTML.

That is fine for a general tool. A phone app that draws a list and one article uses only a few of those fields. The rest is data to download, parse and throw away.

Why the body matters most

The body is the largest part. It arrives as rendered HTML, with the markup the editor and the theme produce. A native app has no browser to render it. It would need extra code to read the HTML, and it would still carry theme markup it cannot use.

I covered the bigger choice, a real app instead of a wrapper, in why WordPress needs a real app. This note is the data side of the same idea.

What a lean namespace does

NativePress is a WordPress plugin with its own REST namespace, nativepress/v1. It takes what authors write in Gutenberg, turns the HTML into light Markdown and serves that instead of the default wp/v2 output.

The Markdown carries only the content. The app, built with Expo and React Native, reads it and draws it with native components. The app decides how it looks. The plugin decides only what content to send.

Authors keep working in the editor they know. WordPress stays the source of truth. You publish once, and the plugin serves the light version to the app.

Try it

The widget below shows one fictional post in two shapes. Switch between the standard WordPress response and an illustrative lean one. The fields and sizes are a sample, and the lean shape is not the real schema. The size is just the length of the sample text on this page. It is not a measurement of any site.

Interactive · toy

The same fictional post as a standard WordPress REST response and as an illustrative lean response.

  • Standard WordPress: many fields, with the body as HTML.
  • Lean: only the fields a screen needs, with the body as light Markdown.
  • The lean shape is illustrative, not the real schema.
  • Sizes are the length of the sample text on the page, not a measurement.

What I am not showing

The public case study shows the idea, the namespace name, the stack and the pricing model in words. I keep customer details and any numbers out. I do not publish figures about speed or size for real sites, because I have none to claim here. If you want to know what lean would mean for your own site, I can look at it with you.

The full story is on the NativePress case study, and there is a short version on the demo page. If you run a WordPress site and want to talk about the API side, see my WordPress development service.

Is a lean feed right for you?

A lean feed suits sites where an app should show posts and pages the way an app does. Tell me about your site and your readers, and I will reply with a one-page recommendation.

Book the free consult

More small toys are on the widgets page, and more writing is in all notes.

What I checked / where this comes from

  • The public NativePress case study on this site: the plugin, the nativepress/v1 namespace, light Markdown, Expo and React Native.
  • The widget uses a fictional post. The standard shape lists fields the default WordPress post output has. The lean shape is illustrative.