Maintenant, c'est fini ça: le moindre service de chat va te proposer son "appli qui va bien", que tu es prié d'installer sinon ça ne marche pas, faute d'utilisation d'un protocole standard.
Ou pas. Ce qu'il se passe la plupart du temps, c'est que les sites webs exposent une API REST en plus de leur API HTML (si j'ose dire). Sur un site decemment concu, ton code metier est package dans une lib, et apres tu construit 2 applis par dessus, une qui expose en REST, l'autre qui expose des pages HTML. Voire parfois, l'appli HTML se contente de faire des appels ajax a l'appli REST, donc l'un dans l'autre....
Le truc c'est que HTML n'a jamais ete un "protocole", c'est une technologie de presentation, ca se limite a ca.
C'est foutrement pratique, ca nous a bien depanne pendant 10 ans parce qu'on avait que ca a se mettre sous la dent, mais maintenant qu'on a des frameworks reellement riches decents et largement diffuses (ios/android), ben les sites s'en servent. Sont pas fous, ca fait des annees qu'ils revent de pouvoir faire des interfaces plus riche avec la souplesse de development web.
Au final, ton appli iOS/Android, c'est surtout une coquille vide qui fait des appels REST/JSON (tout ce qu'il ya de plus standard donc). Tu dois probablement pouvoir t'amuser a sniffer les paquets reseaux et voir ce qu'il passe, une API rest ca a rien de bien compliquer a reverse engineerer.
Ca fait certes du boulot en plus du site web, mais ca permet aussi de faire une application beaucoup plus agreable pour l'utilisateur. Pour reprendre l'exemple donne plus haut du compte en banque avec 3 lignes, j'ai pas forcement envie de me taper les grosses pages bien lourdes et blindees de pubs de ma banque pour verifier que mon flexi felix a bien ete debite. Pour d'autres cas d'utilisation plus pousse, je vais aller sur le site web, mais pour 90% de mes consultations, une simple appli toute bete suffira.
Au final, on reste sur le modele client leger/serveur lourd de ces 10 dernieres annees, on change juste la techno de presentation.
Rien de neuf sous le soleil.
Apres, pour la partie 1 service = 1 protocole.
Regarde ce que font la plupart des applis mobile. Pour l'immense majorite, c'est du read, avec eventuellement un peu de create, parfois du update/delete. Un bon vieux CRUD des familles quoi.
Regarde ce que fait REST avec GET tu implementes 95% de ton appli, PUT/POST/DELETE les 5% qui reste.
T'es libre de reinventer un protocole de communication si tu veux, mais HTTP marche foutrement bien, il est foutrement bien supporte, documente, tout le monde le connait et son seul gros probleme c'est d'etre stateless. Mais c'est sa grande forces (maintenir une connection, c'est pas simple), et le probleme de la session a ete resolue ya facile 20 ans.
Va falloir faire un sacre boulot pour le concurrencer serieusement, a commencer par ajouter le support de ton super protocole a tous les serveurs web/d'applis du marche.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Remercie le mobile
Posté par pasScott pasForstall . En réponse au journal Développement : y aura-t-il une vie en dehors du Web ?. Évalué à 3.
Ou pas. Ce qu'il se passe la plupart du temps, c'est que les sites webs exposent une API REST en plus de leur API HTML (si j'ose dire). Sur un site decemment concu, ton code metier est package dans une lib, et apres tu construit 2 applis par dessus, une qui expose en REST, l'autre qui expose des pages HTML. Voire parfois, l'appli HTML se contente de faire des appels ajax a l'appli REST, donc l'un dans l'autre....
Le truc c'est que HTML n'a jamais ete un "protocole", c'est une technologie de presentation, ca se limite a ca.
C'est foutrement pratique, ca nous a bien depanne pendant 10 ans parce qu'on avait que ca a se mettre sous la dent, mais maintenant qu'on a des frameworks reellement riches decents et largement diffuses (ios/android), ben les sites s'en servent. Sont pas fous, ca fait des annees qu'ils revent de pouvoir faire des interfaces plus riche avec la souplesse de development web.
Au final, ton appli iOS/Android, c'est surtout une coquille vide qui fait des appels REST/JSON (tout ce qu'il ya de plus standard donc). Tu dois probablement pouvoir t'amuser a sniffer les paquets reseaux et voir ce qu'il passe, une API rest ca a rien de bien compliquer a reverse engineerer.
Ca fait certes du boulot en plus du site web, mais ca permet aussi de faire une application beaucoup plus agreable pour l'utilisateur. Pour reprendre l'exemple donne plus haut du compte en banque avec 3 lignes, j'ai pas forcement envie de me taper les grosses pages bien lourdes et blindees de pubs de ma banque pour verifier que mon flexi felix a bien ete debite. Pour d'autres cas d'utilisation plus pousse, je vais aller sur le site web, mais pour 90% de mes consultations, une simple appli toute bete suffira.
Au final, on reste sur le modele client leger/serveur lourd de ces 10 dernieres annees, on change juste la techno de presentation.
Rien de neuf sous le soleil.
Apres, pour la partie 1 service = 1 protocole.
Regarde ce que font la plupart des applis mobile. Pour l'immense majorite, c'est du read, avec eventuellement un peu de create, parfois du update/delete. Un bon vieux CRUD des familles quoi.
Regarde ce que fait REST avec GET tu implementes 95% de ton appli, PUT/POST/DELETE les 5% qui reste.
T'es libre de reinventer un protocole de communication si tu veux, mais HTTP marche foutrement bien, il est foutrement bien supporte, documente, tout le monde le connait et son seul gros probleme c'est d'etre stateless. Mais c'est sa grande forces (maintenir une connection, c'est pas simple), et le probleme de la session a ete resolue ya facile 20 ans.
Va falloir faire un sacre boulot pour le concurrencer serieusement, a commencer par ajouter le support de ton super protocole a tous les serveurs web/d'applis du marche.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.