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.<p>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.<p>I'm not sure where to place the responsibility for these actions. I've considered two scenarios:<p>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.<p>2) Client-centric. Calling /post/create, with the desired tag IDs as a parameter, will create the post <i>and</i> 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.<p>Any thoughts?