Question? Does the client and WEB need to maintain two sets of api code in the same api business logic?

Premise: Have you split the service into multiple microservice questions? Does the client and WEB need to maintain two sets of api code? Is it reasonable to use cross-domain or internal service forwarding if only one api is maintained? Premise: Have you split the service into multiple microservice questions? Does the client and WEB need to maintain two sets of api code? Is it reasonable to use cross-domain or internal service forwarding if only one api is maintained?

Reply content: premise: Has the service split into multiple microservice questions? Does the client and WEB need to maintain two sets of api code? Is it reasonable to use cross-domain or internal service forwarding if only one api is maintained?

I answered this question in a discussion.

At present, we try to use the same set of APIS for apps and WEB (PC and mobile WEB pages). At present, we have not encapsulated so many microservices, therefore, no explicit isolation between the application layer and the service layer is called data APIs! The maintenance cost is the same as you do, so even if the APP homepage and webpage homepage UI are the same, to speed up APP data loading, N requests may be encapsulated into an independent API on the API layer. Then, a public API is called to return the JSON data required by all the home pages at a time, data loaded only from some drop-down lists!

In addition, I feel that you want to use AJAX to directly request your Service API. This is unreasonable. You must call the data API again in the backend language of the project, in this way, there will be no cross-origin issues and it will be safer. It is equivalent that your client project is your application layer!

We have also encountered a tangle problem recently. During the IOS review period, new APIs must be released, but even if we decide to be incompatible with the old version from the business perspective, during the review, old IOS versions still encounter request errors, so we thought of two solutions that are not particularly good. One is program-based logical compatibility, which is definitely a disaster for new users, the other is to always allow the APP version to correspond to a set of API versions, so that the physical code will be more than one, and the source code is very bloated and relatively large, you are welcome to discuss the API multi-version maintenance issue!

Generally, the restful Api design mode is adopted. You only need to maintain a set of APIS, and the client accesses the APIS through cross-origin requests.

No. You only need to maintain the same api authentication method. For example, the access interface must contain the access_token

No matter whether you use cross-domain or internal forwarding, it is a combination solution. Since your system has already been split into two parts, the interface is naturally two independent interfaces, the client should also independently call different interfaces. No matter whether you do it directly or use a combination solution first, you still need to come out independently after all. Otherwise, how can we decouple the two systems? Isn't it the same as not split?