Write API plan — give us feedback

TomasH@kentico.com[email protected] Member, Kentico Staff mod

Hi everyone,

I’m glad I can share with you our plans for content management API (write API). We’re particularly excited about this feature because many of you requested it. In this short discussion, I’d like to share with you our plans to get your feedback and make sure we stay on the right track. Below you can read what we’re planning to develop now and what we’re leaving for later. Please take a moment to give us your invaluable feedback.

Let me start with the most important part — our motivation. Most projects begin with existing content. Content migration to Kentico Cloud could take hours of manual copy-pasting. Hence, this our primary reason for developing Content management API. Apart from that, customers keep asking us how they could store content gathered on their websites or apps. We would be keen to address this issue later in the future when we have more feedback.

  • Could you come up with other relevant use-cases?

Moving on to the second part of the discussion, let me share with you what we plan to develop now and what we plan to leave for future.

To begin with, the existing source of content such as CMS contains two things — content and content models. Content models is a set of definitions such as Content types, Taxonomy or Sitemap.

Although we could automate creating content models too, we see it as a less frequent action. Therefore, doing it manually would be relatively short action.

The biggest task is migrating content items. Hence, we would like to automate this prior to other things. Even though in the first phase you won’t be able to update content models using API, you would be able to get them so that you could assign a Content item to the sitemap or to a Taxonomy term. In our view, there are following two jobs developers would need to do with the API in order to import content.

  • Create or update content items
  • Upload assets to asset library

Looking ahead, let me share with you what we aren’t planning to implement at this point. However, the plan is not final. So, don’t hesitate to share your opinion. Provided we stick to the plan, we would like to implement following features in the future. As soon as priorities allow us to do so.

  • Delete content items or assets
  • Manage content items workflow using API

    • Assign contributor to content items
    • Assign workflow status to content items
    • (Un)publish content items
  • Manage content models using API

  • Manage contributors using API
  • Manage roles using API
  • Manage webhooks using API
  • Manage projects using API
  • Manage languages using API
  • Update content without triggering a webhook

To wrap things up, we plan to make the first step in providing you with a Content management API. We would be grateful for your honest feedback. Could you find a minute to give us your opinion on following questions? Feel free to post a comment here or reach out to me personally at [email protected]

  • Could you come up with any other important use-cases for managing content and content models using API?
  • Provided we stick to the plan, would Content management API help you do your job? If not, what would you miss?

Thanks for helping us.

Comments

  • leelee Member ✭✭

    I think if you are allowing create and update then delete should be there too. CRUD should be the basic feature set.

    I have a situation for example where a site I manage takes in an XML file periodically and creates content items based on the XML file. I have to remove old items that are no longer in the file as well as updating existing ones.

  • TomasH@kentico.com[email protected] Member, Kentico Staff mod

    Thanks for the use-case, @LeeConlin . What kind of import/integration do you perform like that? I'm curious because I see one-time imports more often than ongoing ones.

  • leelee Member ✭✭
    edited July 2017

    I work on a client site where they have a content item called "BookWork" ... they have a bibliographic database that is separate and this database outputs deltas every few hours.

    Their current site reads those deltas on a scheduled task (they are XML files) and imports them as pages of content type BookWork into their current CMS.

    To use Kentico Cloud for them would require that a similar process can be carried out.

    In terms of Kentico Cloud any given "BookWork" - which represents a single bibliographical work item - would have a Title (text), Description (rich-text), Editions (modular content of type BookEdition), OthersInSeries (modular content of type BookWork), etc.

    Another client has a radio station where they allow listeners to browse their track libraries on the website and request items. Again, the library is fed by an XML output from their station software and imported into their current CMS by a scheduled task.

    I understand that a separate database could be used in these cases to hold the custom information, but it would be far nicer to have all content in one place.

  • TomasH@kentico.com[email protected] Member, Kentico Staff mod

    @LeeConlin good news, the CRUD operations on items and assets should be a part of the Content Management API. Please read my recent post which explains the details of planned implementations.

Sign In or Register to comment.