En tous cas, il me semble que pour passer du client web au client natif (navigateur contre application native), c'est HTTP qui s'efface en général, car peu adapté, non ?
Pas forcément et je pense que dans la pratique c'est rarement le cas. Développer un client natif n'empêche en rien celui-ci de communiquer avec une API REST vers un serveur en HTTP ou via les ports 80/443 en priant dans ce cas qu'il n'y ait pas de DPI dans l'entreprise (si c'est pas du HTTP qui passe par les ports 80/443, pan la socket).
En fait, il me semble que c'est plus une question de protocole qu'autre chose, car je ne crois pas que les navigateurs soient autre chose que des purs utilisateurs de HTTP. La question est plutôt de savoir quand HTTP est utile ou non - non ?
HTTP a l'intérêt de passer les firewalls, vu qu'en entreprise ou sur les réseaux GSM 3G, tout est souvent est filtré, même en sortie, sauf HTTP[S]. Une app native passe donc bien souvent par les ports 80 et 443, et elle utilise bien souvent des API REST vers leur serveur applicatif. Donc HTTP ne s'efface pas forcément avec un client natif, loin de là.
La question de HTTP est une autre problématique, étant un protocole stateless four tout, il est à mon avis moins intéressant que XMPP qui maintient une socket bidirectionnelle et permet automatiquement le renvoi de message en cas de coupure réseau. Cependant les websockets qui font partie des bricolages du Web pour s'approcher du desktop, arrivent à maintenir des sockets persistantes pour faire du push vers les navigateurs.
Certains pensent que c'était mieux avant quand chaque app native avait son propre protocole et port IANA dédié, exemple les newsgroup avec nntp (port 119). Le problème est qu'il n'est pas viable que chaque startup qui fasse une app de pets propose auprès de l'IETF un protocole standard de pet et fasse une demande auprès de l'IANA d'un port dédié…
Je vois donc HTTP comme une solution pratique pour ce genre d'app native ; et même le client Dropbox autorise dans ses préférences de passer par un proxy HTTP pour sortir.
[^] # Re: hum...
Posté par fredix . En réponse au journal Bref, j'arrête de développer pour le web. Évalué à 3. Dernière modification le 30 mars 2012 à 23:32.
Pas forcément et je pense que dans la pratique c'est rarement le cas. Développer un client natif n'empêche en rien celui-ci de communiquer avec une API REST vers un serveur en HTTP ou via les ports 80/443 en priant dans ce cas qu'il n'y ait pas de DPI dans l'entreprise (si c'est pas du HTTP qui passe par les ports 80/443, pan la socket).
HTTP a l'intérêt de passer les firewalls, vu qu'en entreprise ou sur les réseaux GSM 3G, tout est souvent est filtré, même en sortie, sauf HTTP[S]. Une app native passe donc bien souvent par les ports 80 et 443, et elle utilise bien souvent des API REST vers leur serveur applicatif. Donc HTTP ne s'efface pas forcément avec un client natif, loin de là.
La question de HTTP est une autre problématique, étant un protocole stateless four tout, il est à mon avis moins intéressant que XMPP qui maintient une socket bidirectionnelle et permet automatiquement le renvoi de message en cas de coupure réseau. Cependant les websockets qui font partie des bricolages du Web pour s'approcher du desktop, arrivent à maintenir des sockets persistantes pour faire du push vers les navigateurs.
Certains pensent que c'était mieux avant quand chaque app native avait son propre protocole et port IANA dédié, exemple les newsgroup avec nntp (port 119). Le problème est qu'il n'est pas viable que chaque startup qui fasse une app de pets propose auprès de l'IETF un protocole standard de pet et fasse une demande auprès de l'IANA d'un port dédié…
Je vois donc HTTP comme une solution pratique pour ce genre d'app native ; et même le client Dropbox autorise dans ses préférences de passer par un proxy HTTP pour sortir.