2017-04-07 11 views
0

Nous avons l'application Android à travers laquelle le détaillant peut recharger les clients mobiles. Nous devons donc autoriser chaque demande de recharge.Comment gérer l'état entre l'application Android et l'API Web ASP.net?

Pour envoyer une demande de recharge, le revendeur doit répondre à l'API avec des informations relatives à la recharge et une ID utilisateur et une clé d'utilisateur. Comme ci-dessous

[AcceptVerbs("GET")] 
    public IHttpActionResult Prepaid(int pUserID = -1, string pKey = "", string pCustomerNo = "", decimal pAmount = 1, int pServiceProviderId = -1, int pDeviceTypeId = -1) 

Nous Authentifier l'utilisateur pour chaque api frappé comparant USERKEY (mot de passe encrypeted) avec mot de passe stockés dans db

Cela fait trop d'appels db et notre serveur devient lent

Son application B2B et le détaillant effectue différentes actions aimables comme l'historique des transactions, demande de crédit, plainte de livre autre que simplement recharger

Comment maintenir l'état après l'utilisateur se connecter à l'application Android

Répondre

0

Eh bien, REST par conception est sans état. En ajoutant une session (ou toute autre chose de ce genre), vous la rendez dynamique et vous annulez tout objectif d'avoir une API RESTful.

Pour obtenir l'authentification et l'autorisation, je l'ai utilisé la méthode suivante:

Alors que la demande de poste utilisateur d'Android, l'utilisateur envoie son code d'utilisateur et mot de passe en-tête d'authentification http et à côté du serveur, nous vérifions le mot de passe et si l'utilisateur est autorisé le nous traiter la demande de l'utilisateur.

Pas besoin de maintenir un état entre android et api web car api sont sans état.

0

Si la clé d'utilisateur est une identification unique pour chaque utilisateur, ou pour chaque numéro de mobile unique, alors je pense qu'il vaut mieux vérifier le numéro de mobile que l'utilisateur utilise pour effectuer la recharge en envoyant un OTP. L'utilisateur peut alors renvoyer ce mot de passe à des fins d'authentification. Mais faites-le uniquement au moment de la connexion, puis enregistrez votre clé utilisateur unique que vous avez générée dans un espace de stockage Shared preference.

+0

Son application b2b n'est pas b2c. et le détaillant effectuent différentes actions aimables comme l'historique des transactions, demande de crédit, plainte de livre autre que simplement recharger – Luqman

+0

Vous n'avez pas besoin d'authentifier l'utilisateur à chaque fois pour une recharge ou toute autre chose. Il suffit d'authentifier l'utilisateur lors de la connexion et de stocker votre "user_key" dans les préférences partagées pour une utilisation ultérieure. –