-
Notifications
You must be signed in to change notification settings - Fork 148
[Feature] Extends search API request #970
Comments
I thought this is by design so that the backend can change the algorithm at any time😲 |
I'm not sure I understand what you are saying. Do you think |
@hemachandarv I see what you mean. I think it is exposed. Is it not? |
@byliuyang I could see there is a param for the resource type. I don't see one for the match type (do we match the keywords in the short-links (or) the long-links?). Currently the app does both and ranks them accordingly. I'm thinking this depends on the use-cases for which the Search is exposed. Do you think we should let the client provide the type of links to match the keywords on? |
My main concern is that each attribute has unique way to be ranked. If we exposed, how are we going to expose ranking logic? Or we can abstract out search layer into a library for additional use cases? Could you please draw some UMLs or explain sample exact use cases? I can't just imagine the use cases themselves without knowing what they are. Thanks! |
The ranking param & code are in pair. |
I completely agree that each attribute has unique way to be ranked. For now, I see we allow link search only, based on the provided keywords. From what I see in the code, I could think of an use-case where a client wants to get links for the keywords that are matched only in short-link. However, the application returns matches from the long-links as well. This could become an issue if there are no matches in the short-links for the given keywords. I do not know the current use-cases supported by Search. Would love to know them. |
@hemachandarv I am trying to not expose how order is calculated to the client. That's to be said, we are planning to make a generic search engine library for developers to integrate search feature into their own system. |
@hemachandarv How about this. Let's expose the API to allow the client to decide what fields we want to be sorted on. If nothing is specified, by default, we sort on both fields. |
What is frustrating you?
Clients of Search API cannot determine directly whether the returned link is matched for Short (or) Long link. Also, clients do not have control over the type of links searched for a particular request.
Your solution
Accept a match-type parameter (Short/Long/All) in the request and return the matched links in the response as separate arrays (ShortLinkMatches / LongLinkMatches).
Additional context
Explored as part of #866
The text was updated successfully, but these errors were encountered: