How to modify the api path corresponding to the data

[An0nymous0]

Because some backends may be non-standardized restful api How to customize the interface address corresponding to the page
。

[BatuhanW]

Hello @An0nymous0, you can use different data providers for different resources, see the documentation here:

https://refine.dev/docs/api-reference/core/providers/data-provider/#multiple-data-providers

Feel free to re-open it, if this doesn't answer your question.

[vinclou]

@An0nymous0 First of all I would assume you are using Rest Api data provider package.

If so, just take the core implementation from the github and modify it to your own needs, but this can be done to any data provider.

Once you done just import that into App.tsx and pass that as props to your Refine wrapper instead of the generic ones offered by the team.

And remember it's just JavaScript underthehood:)

I had no problem modifying or creating custom stuff on top of the core library.

[An0nymous0]

Thanks, I have read the related material, but the method in the address is only applicable to the whole backend of the centralized package, generally there are multiple collaborators in the project, we assume that the quality of collaborators are not the same, the project api path There are subtle differences, how will I cope with this situation.

For example: the user list interface provided by developer A is get /user, the user modification interface provided by developer B is

post /user

request body  Content-Type:application/json
{id:1,username:'xxx'}

[An0nymous0]

@vinclou I wonder if there is such a way to deal with some situations outside the standard rules

resources={[{
            name: "users", 
            list: {
                path: "/users", component: UsersList, requestDataConfig: {method: 'get', path: '/userList'} #<< Custom Override Configuration
            },
            create: "/users/create",
            edit: "/users/edit/:id",
            show: "/users/show/:id",
          }]}

The advantage of this is that if I encounter individual non-standard addresses I can temporarily override the standard by configuring

[vinclou]

I think there's a misconception happening here about how router provider works, I can send you example when I get to work. But generally, the use case where you are concerned GET vs POST should make any problems for you

Or maybe I misunderstand something here

[An0nymous0]

I'm a refinedev newbie and my thought is to have a place to configure to override the default access request path to cope with the differentiation of the backend address, if I don't then the default goes to the custom data providers

[An0nymous0]

Our back end is not as standard as https://api.fake-rest.refine.dev and often varies widely


[vinclou]

Well unless all of them are REST based, there're no SOAP/GraphQL/gRPC Apis there shouldn't be conceptual differences it's just REST endpoints they are behaving same across frameworks and languages. You might need to customize things like query parameters or default hooks like useUpdate etc => We have a microservice architecture and have like 20 API access points, but even then we combine it into one with API gateway once deployed

[An0nymous0]

Suppose my user list interface address is https://api.fake-rest.refine.dev/userList, my project list interface address is https://api.fake-rest.refine.dev/project, and my category list interface address is https://api.fake-rest.refine.dev/categorys

I don't know how to respond, multiple-data-providers shouldn't solve my doubts

@BatuhanW @vinclou

[vinclou]

@An0nymous0 I think you have conceptually misunderstood data provider, it makes the string URLs for you, you pass React page components to it to handle whatever happens on the route here's example of my set-up. It actually uses both many data providers and
custom data provider which I wrote because how we handle query params and some PUT/PATCH/DELETE calls, but this is on the API level.

[vinclou]

To clarify, all the different dataProviders shown in the first picture actually used for query invalidation, since Refine handles invalidation on route basis, it was hard with our design to invalidate only what we need, the most simple solution was to put heavy reqs on different route providers and manually invalidate them if ever needed. The default data provider is used to do most of the requests and could do any of the providers below.

And I think the use case was intended to be used as are completely different points to fetch the data. I would think this might be an anti-pattern, but query invalidation story needs to be better after all.

[vinclou]

As you can see, I'm passing react components not strings => and overall if you ever want to control what happens on the page, you can always modify what's being fetched by custom hooks on page level. T.e since we have public and internal (hidden) API I pretty much do it across the board where I use custom resource paths on every page and don't use the one that comes from the provider

[An0nymous0]

@vinclou Thanks I seem to understand, thank you for your reply