Any update on above requirement.
Sorry for the late response on this.
It would take a fair amount of work to do an exact mapping (and there will undoubtedly be a few small gaps), but I can speak to at least these issues:
Tags - in every case where tags are supported (people, places, and content) tags are a String array on the object itself. For that reason, a separate tag service is not needed in V3. As an example, see how tags are documented on a document object. To update the tags on a document, you could do something like this:
- GET /api/core/v3/contents/1234 - Retrieve the full representation of this document (use ?fields=@all query parameter if you use some other API to retrieve it)
- Update the "tags" field, represented as an array of strings
- PUT /api/core/v3/contents/1234 - Put back the updated document, including the updated tags
ForumService - Forum threads surface in V3 as objects of type discussion, and forum messages surface as objects of type message. As with documents, status updates, and so on, discussions do not need any endpoints of their own. Instead, they are visible through the unified content service endpoints. Once you have received a discussion object, you can do things like iterate through the reply messages for that discussion by following the URI in the "messages" object in the "resources" field.
Community Properties - V3 follows the terminology of recent versions of Jive's UI, so what was called a community is now called a space object. In a fashion similar to how the unified content service works, all places (blogs, groups, projects, and spaces) are visible through the unified place service endpoints.