Deprecating many Confluence v1 APIs that have v2 equivalents

Confluence Development Confluence Cloud Announcements
, , ,
41

Hi @TylerBrown, In our app we need to have the space icon, so currently use the following expand to see that:

/wiki/rest/api/space/EX?expand=icon

But using the replacement:

/wiki/api/v2/spaces/:spaceId

It appears that space icon is not present, so is there a separate v2 API for that?

Or just like avatars, is there a URL I can build similar to:

https://instance.atlassian.net/wiki/aa-avatar/:accountId

e.g. maybe something like…

https://instance.atlassian.net/wiki/space-avatar/:spaceId
1 Like
42

Hello,
I have posted my query here Unable to find page's tinyui, base and webui

But reposting here again, to gain attention.

I was using v1 rest API response’s following params, tinyui, base and webui, but unable to find these any more in v2 API’s response. Is there a way?
V1 API Response: /rest/api/content/{pageid}

{
   "id":"734397355",
   "type":"page",
   "status":"current",
   "title":"markdownPageUrlRelReplacementVars",
   ...
   ...
   "_links":{
      "editui":"/pages/resumedraft.action?draftId=734397355",
      "webui":"/spaces/zmarkdown/pages/734397355/markdownPageUrlRelReplacementVars",
      "context":"/wiki",
      "self":"https://bobswift-prod.atlassian.net/wiki/rest/api/content/734397355",
      "tinyui":"/x/qwPGKw",
      "collection":"/rest/api/content",
      "base":"https://xxxxxxx.atlassian.net/wiki"
   }
}

Unable to find these any more in V2 API Response equivalent API: /api/v2/pages/{pageid}

{
   "id":734397355,
   "version":{
      "number":2,
      "message":"",
      "minorEdit":false,
      "authorId":"xxxxxxx",
      "createdAt":"2023-03-29T09:24:13.587Z"
   },
   "parentIdString":"734396510",
   "idString":"734397355",
   "spaceIdString":"734396418",
   "title":"markdownPageUrlRelReplacementVars",
   "status":"CURRENT",
   "body":{
      
   },
   "parentId":734396510,
   "spaceId":734396418,
   "createdAt":"2022-10-18T06:41:40.076Z",
   "authorId":"xxxxxxx
}

Can someone please help?
Thank you

1 Like
43

I have investigated which deprecated APIs we are using and what replacement there is for them. I have not yet investigated the performance impact of the new API.

There are a few API endpoints that I couldn’t find a replacement for:

  • There seems to be no complete replacement for the children.* expansion. While there are APIs to retrieve custom content children of pages/blogposts/spaces, there is no API to retrieve custom content children of custom content. Also (not relevant for us) I noticed that there seems to be no API to retrieve child pages of pages.
  • When creating a page, there seems to be no (documented) way of setting the parent page.
  • There seems to be no API for deleting attachments. While the old APIs for creating and updating attachments are not deprecated, for deleting attachments we were using the delete content API.
  • There seems to be no API to retrieve a space by key, only by ID? Do we need to fetch all spaces in the Confluence instance to find the space? If so, I think some users have ten thousands of spaces, so this is not acceptable. Confluence stores space references by key, so how can we resolve them?
  • There seems to be no replacement for the operations expansion on pages, blogposts, custom content and spaces. Do we need to run the Check content permissions API for each permission type, and is it performant to do so lots of times?
  • Similarly, I was not able to find a replacement for the permissions expansion for spaces.
  • I could not find a replacement for the homepage expansion for spaces.

I also noticed that the ?body-format=storage parameter for the /wiki/api/v2/*/{contentId}/versions parameter works but is not documented.

3 Likes
44

Can the v2 ‘get attachments’ endpoint please be updated to include the “fileId” field that is returned on the v1 data.

V1 looks like:

Screenshot 2023-03-31 at 13.09.56
Screenshot 2023-03-31 at 13.09.56964×417 49.1 KB

While V2 looks like:

Screenshot 2023-03-31 at 13.10.47
Screenshot 2023-03-31 at 13.10.47919×337 46.3 KB

The “fileId” field is required when working with ADF content, for example here is the data of a ‘mediaSingle’ node representing an image:
Screenshot 2023-03-31 at 13.15.50

The ‘id’ in the ADF attributes can be used to match the ‘fileId’ field on the v1 endpoint. Switching to the v2 api, no such matching is possible.

45

@candid For this use case, you can use GET /wiki/api/v2/spaces?keys=SPACEKEY, which works reasonably well.

But another missing API in v2 is an equivalent for the deprecated PUT /wiki/rest/api/content/{id} for attachments. You used to be able to use this to change the status of the attachment (current/trashed/deleted/historical), but there is no longer an equivalent in v2.

1 Like
46

Hi Atlassian (@AlexWilliams @TylerBrown and others),

Could we please get some sort of public statement from Atlassian on your intentions for this deprecation? This was announced already a month ago, and in the meantime, the community has provided numerous examples of incomplete, broken (eg. ids as numbers), or completely-absent APIs. That leaves five months left for implementation (of which two months are in the summer, when many teams take vacation).

It would really help to have some guidance on the timeline (are you really sticking to six months from Feb even though no equivalent APIs are available yet?), as well as some feedback on how you are going to address all of the other issues.

In the case where you can’t commit yet to how you are going to address those issues, it would still help us by telling us, now, when you hope to give us that information, as well as any guesses about how you might fix the problems, and also telling us how all this will impact the timeline as a result.

Thanks!

1 Like
47

Hi @scott.dudley ,

Thanks for checking in, sorry for the delayed response. We will be posting an update related to this and other changes on Monday.

Thank you!

1 Like