Thank you for requesting our input on this. It is appreciated 
I do have a some points:
- My biggest concern is that differentiating between pages and blogs, which are both content types that accept macros from our apps, is going to create unnecessary complexity in our apps. We have to code the apps to use the appropriate APIs to basically just get some fields that are common between them. So it shifts complexity from you to us. Plus the migration work that would have to be done. If we could just get an endpoint that would just return some common metadata between the two please? Stuff like title, space, version, body? (almost all of our Confluence apps are macros, so this is my main point)
- Basically what Boris already said. It would be hugely helpful if you could somehow let us know which deprecated endpoints our apps are using. There could be a bunch of factors why we would miss our apps using these endpoints, so as a vendor who’s responsible for a decent amount of apps, this would be a great help. Ideally this would be updated on a weekly or so basis as the deprecation period progresses so we can make sure we’re not missing anything. Ideally, this could be used as well for other API deprecations.
- This does not affect us I think, but I could see some people being put off by the cursor change which does not provide the total number of items to be returned. This makes paginated lists (such as the Dynamic Table Atlaskit component) terrible to use from a UX perspective because you never know how many pages there are remaining.
- I think the GraphQL APIs have some great potential to be replacing the V1 REST APIs as well, but they do not support some of the features we would require. I think the big one I bumped into recently was its inability to handle unpublished pages / page edits, but I’m not 100% sure about this. Also it would be nice if the GraphQL API docs would contain the OAuth2 scopes required for a certain field.
Thank you for your time and consideration!
Cheers,
Tobi from resolution