Deprecating many Confluence v1 APIs that have v2 equivalents

[riku]

I shared our use case in more detail on the original blog post announcing the v2 endpoins:

Release of v2 Confluence REST API for Pages and Blogposts (Experimental)

Hi @TylerBrown ! We (I’m working with @SvenSchatter and @christoffer ) have some concerns about how our app would perform if expansions are not supported. We have use cases where having to fetch all the information that is needed by our app without using expansions could potentially lead to tens of thousands of requests on Confluence instances of some of our customers. Currently all the needed information can be fetched with a single REST call that has several expansions. It is true though, th…

I think that our team is fortunate in the way that all the data we use - at least in the most important use cases - is already available on the v2 endpoints. And I can also see many positive things about the change, for example the cursor based pagination.

My main concerns are about performance - apart from the significant amount of work that will be needed for migrating away from the deprecated endpoints.

One use case that our app has, is to get all pages in a space (or a page tree) and expand labels, children, and content properties. Doing that with the v1 endpoints and expansions is not always very fast, but it’s not very slow either. Typically getting a response page that has the required data for 200 pages takes something like 5 to 10 seconds.

With the v2 API we will first need to get a response page with basic information about 200 Confluence pages, and then additionally do 3 REST calls for each of those. So we will need to do 600 (+1) REST requests to get the same data that we got with one v1 request.

If v2 API has around 200ms response time for each of those 600 requests, it would take 600 * 0,2 seconds = two minutes to get all the responses if we would run the requests one after each other.

So we obviously need to do lot more requests concurrently than we’re doing now. To get to the 5-10 seconds time that our customers expect using the v2 endpoints, about 15-30 request would need to be run in parallel all the time.

Additionally, we’re using several threads for handling different spaces / page trees in parallel.

So to get actual performance benefits we would probably need to have at least 100 REST requests to v2 APIs in-flight at the same time.

–

But maybe this is not a problem with the v2 APIs. If that’s the case, then this change can be great for our use case, especially if it also brings stability benefits. We have seen also cases where the v1 endpoints get very slow even though that’s not very common with the simple expansions that we use.