Implement named fetchers #87
Conversation
By default the used fetcher is chosen by content uri. We may however want to choose a specific fetcher in case of multiple fetchers implementing the same content uri. This patch adds fetcher identifiers that can be used to request a specific fetcher.
|
Why would you want to use a different fetcher for same URI? It would seem to violate the principle that one URI comes from one source of truth.. or am I missing something? |
|
In my use case there are multiple API endpoints for the same kind of content. E.g. a search for Items at /api/search?q=term, top list of Items at /api/top50, and currently trending Items at /api/trending. They all return the same kind of Item lists, so I want to use same stores for them. |
|
Hmm I see. Do you have a code example of how to use these? Ideally I guess fetchers should operate independently of the URI, since we do not always know or care what kind of data they return - it could be a combination of many. URI structure and query URL structure do not need to match. However, it is probably useful to have one "standard" place where to get data for a given URI regardless of where it originally came from the first time. |
|
There's example included in this patch, https://github.com/reark/reark/pull/87/files#diff-58e200b3ecb7ac000eb58c5fec1f452bR75 |
|
Closing this, a bit different approach at #88. |
By default the used fetcher is chosen by content URI. We may however want to choose a specific fetcher in case of multiple fetchers implementing the same content URI. This patch adds fetcher identifiers that can be used to request a specific fetcher.