nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Child Item

changes copy_v2, create_folder_v2, Etc.

Ed-

Hello, I resumed to develop a project that I started about three monts ago and I found that for some of the things that I had already done and finished the API changed.

They are: copy was replaced by copy_v2, create_folder by create_folder_v2... also there are delete_v2, and move_v2 as far as I saw.

In a first look, it doesn't seem to be much change, I only noticed that the result changed for delete_v2 but I didn't compare in all detail every API endpoint.

My question is, is there any document where I could easily see what the changes are in order to convert my code without having to study all again and compare in detail all the API endpoints that changed?

Find more posts tagged with

API

Abuse

Comments

Greg-DB

We don't have a document detailing the differences in these endpoints, but I'll be sure to pass this along as feedback.

For reference, in this case, we deprecated these endpoints in order to offer a different return type. For example, the /2/files/move endpoint returns Metadata, while /2/files/move_v2 returns RelocationResult. For now, RelocationResult only contains a Metadata, but using this different type allows us to expand the information returned by this endpoint, e.g., to offer information about the operation itself, without changing the definition of Metadata everywhere.

While we recommend migrating offer of these deprecated API v2 endpoints to their non-deprecated replacements, right now it isn't essential. We haven't announced any retirement timeline for these deprecated API v2 endpoints, so they will continue working. If/when we do need to retire them, we will be sure to reach out to any developers still using them with advance notice.

Ed-

Yes, but that makes me question whether I'm doing right in writing a component to provide an easy and intuitive interface for your API, since if the API's endpoints are changing so frequently, my component will be rendered outdated soon.

If I sell this component to other developers that use it on their applications, I would like to have the confidence that it will work for several years.

Microsoft is not a good example in anything, but they usually guarantee at least for ten years their technologies to work.

I already worked about two or three months on this project, it converts many of your asynch API calls into synch functions in an object oriented schema.
It keeps locally the information of what is in a Dropbox account, and keep it synched calling to list_folder/longpoll
But now I'm wondering if I have chosen the right niche to work on.

Greg-DB

Thanks for the feedback! I'm sending this along to the team.