Child Item

/files/search deprecation and how it relates to the JavaScript SDK

Hey there,

With regard to the deprecation of the /files/search endpoint, I'm curious how it relates to the JavaScript SDK. We're using an older verison of that SDK for our integration, and I'm wondering if we can just upgrade our version and have it use the /files/search_v2 endpoint.

I know we're hitting /files/search from looking at our logs, but I can also tell we're not calling the `filesSearch` route (https://github.com/dropbox/dropbox-sdk-js/blob/8802f727e48352cf7d2bbacef91e53931eacafbb/lib/routes.js#L1027) directly, so it must be called from somewhere else in the code. So as long as we don't call `filesSearch` directly, can we be sure we'll avoid the files/search endpoint?

Find more posts tagged with

API

Abuse

Comments

Greg-DB

The /2/files/search endpoint is deprecated and is being retired in favor of the /2/files/search_v2 endpoint (and /2/files/search/continue_v2 for the pagination of results following /2/files/search_v2). Each of these endpoints correspond to one method in each official SDK. In the JavaScript SDK, that's:

Only filesSearch in the SDK calls the deprecated /2/files/search. In order to migrate from the deprecated endpoint to the new ones, you should replace any usage of filesSearch in your app with filesSearchV2 and filesSearchContinueV2.

shalgrim

Thanks so much for your help, Greg. I have some follow-ups.

We are currently on an old verison of the SDK. 2.5.12 to be exact, so we have some catching up to do.

My concern is still about the files/search endpoint that is about to be deprecated. We are seeing calls to that endpoint that are coming from places other than the filesSearch method. I don't know where they're coming from, but I can rule out they're coming from there. I have a hunch that it might be from filesListFolder or filesListFolderContinue.

So, is it the case that other functions in the SDK call filesSearch? What version of the SDK do I need to get to so that I can be sure that by eliminating all of our calls to filesSearch that files/search will never be hit?

(Context: If I jump all the way to 9.0.0 all of our tests fail. I've managed to so far get up to 5.1.0 and still have a working test suite, but even going from there to 6.x causes everything to fail.)

Greg-DB

Can you elaborate on what you mean when you say you "are seeing calls to that endpoint that are coming from places other than the filesSearch method"? Can you share what you're seeing specifically in that regard? None of the other methods in the SDK should be calling that endpoint.

For instance, filesListFolder just calls /2/files/list_folder, and filesListFolderContinue just calls /2/files/list_folder/continue.

Also, for reference, you can find information about the changes between the versions in the release history and upgrading.md.

shalgrim

> Can you elaborate...

Right, well, in our logs I'm seeing calls to the files/search endpoint, but I can't trace how it gets there. We only call `filesSearch` in a single place; but the function from which I'm seeing the calls to the files/search endpoint do not call `filesSearch`. We're way back on version 2.5.12. This may not be a question you can answer, and that's fine, but it's very suspicious.

I do want to follow up on this bit, though:

> you should replace any usage of filesSearch in your app with filesSearchV2 and filesSearchContinueV2.

It seemed like `filesSearch` handled calling `files/search/` and `files/search/continue`. But now it seems like with moving to V2 we need to manage the continue call manually ourselves? In other words, we used to be able to call `filesSearch` and it did any continuing necessary under the hood but now we have to manage that ourselves?

Finally, one more question. I've noticed that the files/search and files/search_v2 endpoints return different results for the exact same query. Do you have documentation on what changes were made there?

Thanks!

Greg-DB

I can't think of any reason you'd be seeing more calls to /2/files/search without actually calling filesSearch. For reference, here's a link to the code from v2.5.12 of the SDK, and the only reference to files/search is in the filesSearch definition. Could you perhaps share the relevant code you mention here: "the function from which I'm seeing the calls to the files/search endpoint do not call `filesSearch`" so we can take a look?

Also, filesSearch did not actually automatically handle the pagination for you. And there actually wasn't an equivalent /2/files/search/continue endpoint. The pagination for /2/files/search (and so for filesSearch) was handled by calling /2/files/search (filesSearch) itself again. With the SDK, when calling filesSearch you are supposed to check the returned FilesSearchResult.more to see if there are more results to retrieve, and then call filesSearch again, supplying the FilesSearchResult.start as FilesSearchArg.start, if so.

In the new version, using filesSearchV2 and filesSearchContinueV2, the pagination is built somewhat differently and uses the two separate endpoints, so you would instead check FilesSearchV2Result.has_more and use FilesSearchV2Result.cursor instead of a "start" value.

Finally, yes, the two search systems work a bit differently. You can find more information in this blog post.

shalgrim

Thanks again, so much!

That's a great blog post, and I have a follow-up.

Is there a set of parameters I can send to search_v2 so that it will return the same results as search? I imagine we'll want to take advantage of the greater set of results, but just in case we run into cases it would be nice to have this in our back pocket.

Thanks!

Greg-DB

No, the two work a bit differently so their options and functionality don't map exactly to one another, so there isn't really a way to make them behave exactly the same way.