I’ve been attentively following the announcements regarding the deprecation of numerous V1 rest endpoints in Confluence. While I wholeheartedly understand and respect the pursuit of progress and innovation, this decision brings forth several pressing concerns:
1. Maturity of V2 and GraphQL: The current V2 API seems to lack essential features, and many critical GraphQL capabilities remain in beta. Furthermore, to my knowledge, the GraphQL API isn’t even accessible for connecting apps at this juncture. Transitioning to Forge isn’t an option for us, and many developers share this sentiment due to Forge’s existing limitations.
2. Dependence on Expands in V1: Our systems, along with many others, heavily depend on the “expands” feature in the V1 API. With the proposed changes, this critical data access could be hampered, potentially rendering integrations and specific functions unviable. Neither V2 nor GraphQL offers a suitable replacement.
3. Partial API Transition: While I’m always open to embracing newer API versions, it’s baffling that the decision has been made to deprecate substantial sections of the old API, when its successor isn’t wholly prepared to assume its responsibilities. This situation leaves us oscillating awkwardly between two distinct APIs.
4. Relevance of Content IDs: Our application greatly values the adaptability of content IDs, which can signify a page, blog post, or comment. Eliminating this functionality would necessitate a significant overhaul of our app’s logic.
5. Export View: Our application uses the export view, to my understanding the export view cannot be accessed at all with the V2 api.
6. Potential Workarounds: Given that the search API endpoint seems to endure, as evidenced by this documentation, it begs the question: Could this serve as a viable alternative for the “get content” API? If we frame CQL for ‘get content with id = 123’, it might work and we might adjust our app without to much work but pushing vendors to go down this path seems counterproductive, especially if the objective is performance enhancement.
Given the issues outlined, I respectfully request a revisit of this decision or, minimally, a well-thought-out plan ensuring a smooth transition that doesn’t compromise on key features and data access. The developer community deeply values stability and clarity, and we earnestly hope these concerns will be considered during this critical transition.
I must emphasize: I genuinely appreciate the direction of Forge and V2 and I’m not against change per se. However, it’s disheartening to see vendors continuously nudged towards adopting solutions that seem incomplete or not fully baked. This is very frustrating and I’m worried about the stability of our app when we’re forced to move to using apis that are still in beta state.