Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consolidate SearchAssets and GetAllAssets API #201

Open
bsushmith opened this issue Jan 25, 2023 · 1 comment
Open

Consolidate SearchAssets and GetAllAssets API #201

bsushmith opened this issue Jan 25, 2023 · 1 comment

Comments

@bsushmith
Copy link
Member

bsushmith commented Jan 25, 2023

Is your feature request related to a problem? Please describe.
The SearchAssets(/v1beta1/search) endpoint and GetAllAssets(/v1beta1/assets) endpoint are very similar and their general use cases are similar. It doesn't make much sense to maintain and actively develop similar features for both endpoints., and they can be consolidated into one single endpoint.

Ideally, SearchAssets should be able to handle both these features as it is comparatively full-fledged and also has elastic search as the data source driving that API. Both endpoints support sorting and filtering capabilities in their own way.

feature SearchAssets GetAllAssets
sort
pagination
filtering 🛠
search_text 🛠

Describe the solution you'd like
One API to simplify development and maintenance for both search and list. This should be through the SearchAssets API.

@ravisuhag
Copy link
Member

@bsushmith IMO both APIs have different objectives.

  • Search is mainly for providing free text search while list api is for listing.
  • Search should only return indexed object/data of asset while list will return more fields. Hence search should also not really need fields filters.
  • Search will also provide sorting based on relevance etc while list won't.
  • In future search will work across assets, discussions etc. while list of each of these will be different.

I think we should move more towards clearly defining functions of both. But we for sure will need both. cc @StewartJingga @AkarshSatija

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants