Ghost: Content API V2: does not return mobiledoc

[rishabhgrg]

_(refs #9866)_

Why do we remove mobileodoc from Content API v2?

Going forward, we want Content API to be very stable and dependable read-only API. Currently there is no usecase which justifies the need for sending mobiledoc as a default field on resource, so unless a clear use case or need appears, we remove mobiledoc from response of Content API.

This serializsation will happen in the the Content V2 input serializer.

[okcoker]

I know this is a bit old but if you're using the Ghost API to display content on multiple platforms including non-html environments, wouldn't that be a good enough use case to allow for mobiledoc within the Content API? How does removing it make the API more stable and dependable?

[kevinansfield]

@okcoker there are currently no non-html renderers and mobiledoc is an intermediary format with Ghost-specific cards so it's not as straightforward as grabbing the mobiledoc and having a generic renderer available. We also plan to add and adjust cards over time, as well as enable custom cards to be installed on a per-instance basis which would mean there's even more difficulty in keeping a custom renderer in sync with the whole ecosystem.

The Content API is intended as a _public_ API, if we extend the format to include editor comments and other non-public data we suddenly need to have two different mobiledoc output serialisers so that it can be sanitised for public use. If you really want to use the raw mobiledoc data then the Admin API is always available for use in server-side or non-public environments.

[mossymaker]

@kevinansfield: My use case is similar: using Ghost headless with Gatsby. I'm following gatsby.ghost.org and want more control over how posts are rendered (e.g. styled-components); not having the mobiledoc representation makes that impossible.

Removing mobiledoc from the content API seems counter to the intent and spirit of _mobiledoc_ and Ghost's own headless guide.

There doesn't appear to be a real justification for removing the format and your response to this use case is kind of a nonanswer...can you please address this question from earlier:

• > How does removing it make the API more stable and dependable?

I think a better solution would be to make the mobiledoc format optional without removing it. I want to address a few of your points with that in mind:

• > Mobiledoc is an intermediary format with Ghost-specific cards so it's not as straightforward as grabbing the mobiledoc and having a generic renderer available. We also plan to add and adjust cards over time, as well as enable custom cards to be installed on a per-instance basis which would mean there's even more difficulty in keeping a custom renderer in sync with the whole ecosystem.

None of these seem to be the API's concern. If someone wants to accept those caveats and work with the mobiledoc anyway, they should have that option.

• If we extend the format to include editor comments and other non-public data we suddenly need to have two different mobiledoc output serialisers so that it can be sanitised for public use.

  Being an _if_, this seems like it could be addressed later when that becomes a concern.

• If you really want to use the raw mobiledoc data then the Admin API is always available for use in server-side or non-public environments.

  Using the admin API would mean writing new tools when they already exist for the content API, e.g. _gatsby-source-ghost_. Since that's the only option right now, that's what I've done with gatsby-source-ghost-admin.

[okcoker]

@mossymaker I agree with your comments.

The additional mobiledoc output serializer seems to me like it would need to be done anyway if you're going to include _more_ mobiledoc data, even if it's only going to be in the admin api mobiledoc response. The part of the serializer that does the potentially non-public data can maybe be a plugin of some sort within the main serializer so the content api doesn't have to worry about it. Where there's a will, there's a way.

Anyway, I've since forked ghost and re-enabled the mobiledoc within the content API for my use case. I didn't go with the admin API as it requires more credentials that would potentially be exposed on the client/browser. I planned (and still plan) on following up here when I reach a more tangible state with my project.

[glenpike]

I agree with the posters above. I've been investigating using Ghost as a CMS as well as a blog. We need more control over the rendering of our content and mobiledoc seems like a possible way we could do this. Contentful provides similarly structured data via it's API, so currently seems like a better option.