Ask HN: Building a CMS – Client or API Centric

I'm in the advanced stages of building a CMS, from scratch. I've finally got around to adding support for tags - i.e. "#Microsoft #smartphones" on an article about a Lumia, to help you find articles.

I've run into a major architectural issue I'd like some insight in. The tags and posts are stored in separate tables and linked via a posts_tags table with foreign key to join the two. Therefore, to create the post and tags, requests are required to both /post/create and /taglinker/create on the API.

I'm not sure where to place the responsibility for these actions. I've considered two scenarios:

1) API-centric. The client calls /post/create and the post itself is created. The client then has to make its own requests to /taglinker/create to handle adding the tags. This maintains the API's integrity - each endpoint has one very obvious purpose.

2) Client-centric. Calling /post/create, with the desired tag IDs as a parameter, will create the post and transparently link all the specified tags. The API takes responsibility, calling /taglinker/create as many times as required from /post/create. This would be much easier to implement client-side but would lead to some blurring of the capabilities of each API endpoint. This could be acceptable though, since it can be assumed that a call to /post/create will invoke calls to /taglinker/create, so the API linking the tags could be perceived as it just fulfilling the intended function.

Any thoughts?