person:ruben verborgh

AF_Sobocinski @af_sobocinski CC BY-NC-ND 25/08/2016

11

11

Non, je ne veux pas télécharger votre & µ$# d’#application ! – Framablog
▻https://framablog.org/2016/08/25/non-je-ne-veux-pas-telecharger-votre-%c2%b5-dapplication
« Ne voulez-vous pas plutôt utiliser notre application ? »…
De plus en plus, les écrans de nos ordiphones et autres tablettes se voient pollués de ce genre de message dès qu’on ose utiliser un bon vieux navigateur web.
Étrangement, c’est toujours “pour notre bien” qu’on nous propose de s’installer sur notre machine parmi les applications que l’on a vraiment choisies…
Ruben Verborgh nous livre ici une toute autre analyse, et nous dévoile les dessous d’une conquête de nos attentions et nos comportements au détriment de nos libertés.
#internet

AF_Sobocinski @af_sobocinski CC BY-NC-ND
- Monolecte 😷🤬 @monolecte CC BY-NC-SA 26/08/2016
  
  Pourquoi les éditeurs de contenus préfèrent-ils les applications ? Parce-qu’elles leur donnent bien plus de contrôle sur ce que nous pouvons et ne pouvons pas faire. Le « problème » avec les navigateurs, du point de vue de l’éditeur, est qu’ils appartiennent aux utilisateurs. Cela signifie que nous sommes libres d’utiliser le navigateur de notre choix. Cela signifie que nous pouvons utiliser des plugins qui vont étendre les capacités du navigateur, par exemple pour des raisons d’accessibilité, ou pour ajouter de nouvelles fonctionnalités. Cela signifie que nous pouvons installer des bloqueurs de publicité afin de restreindre à notre guise l’accès de tierces parties à notre activité en ligne. Et plus important encore, cela signifie que nous pouvons nous échapper vers d’autres sites web d’un simple clic.
  Si, en revanche, vous utilisez l’application, ce sont eux qui décident à quoi vous avez accès. Votre comportement est pisté sans relâche, les publicités sont affichées sans pitié. Et la protection légale est bien moindre dans ce cadre. L’application offre les fonctionnalités que le fournisseur choisit, à prendre ou à laisser, et vous ne pourrez ni les modifier ni les contourner. Contrairement au Web qui vous donne accès au code source de la page, les applications sont distribuées sous forme de paquets binaires fermés.
  
  Monolecte 😷🤬 @monolecte CC BY-NC-SA
Écrire un commentaire
Stéphane Deschamps @notabene CC BY-NC-SA 12/12/2013

3

3

The lie of the API | Ruben Verborgh
▻http://ruben.verborgh.org/blog/2013/11/29/the-lie-of-the-api
Futuristic? It’s not: it works already, and it’s really simple. Here is a designer chair from the Cooper-Hewitt museum:
▻http://collection.cooperhewitt.org/objects/35460799
The cool thing is that machine clients use the same URL to access a JSON version:
curl ▻http://collection.cooperhewitt.org/objects/35460799 -H “Accept: text/html”
curl ▻http://collection.cooperhewitt.org/objects/35460799 -H “Accept: application/json”
Not only does this enable to share URLs between different parties, it also makes access really simple. I don’t have to read the manual. Instead, I just use the same interface I use every day: the URL. Works the same way everywhere.
This technique is called content negotiation and it is a characteristic of REST APIs.
Voui voui voui. Chouette article qui met la pile aux gens qui compliquent à loisir.
- #Ruben Verborgh
- #API
- #HTML
- #JSON
Stéphane Deschamps @notabene CC BY-NC-SA
- RastaPopoulos @rastapopoulos CC BY-NC 13/12/2013
  
  #API #REST #content-negotiation #mime-type #HTTP #URL
  Mais souvent pour faciliter les clients, c’est plus facile de leur faire passer des paramètres en get ou post que de leur demander de savoir gérer les entêtes HTTP. Enfin j’avais l’impression. (Moi-même étant assez nul en connaissance d’entêtes HTTP au passage.)
  
  RastaPopoulos @rastapopoulos CC BY-NC
- severo @severo PUBLIC DOMAIN 13/12/2013
  
  URLs identify concepts, and each URL can have multiple representations. This means that a single resource can be identified with one URL for all clients . Each client just indicates to the server whether it wants HTML or JSON or something else, and the server replies with a representation the client understands.
  This lack of knowledge comes from developers being all too familiar with the programming-oriented environment they usually work with, but mostly oblivious about the resource-oriented nature of the Web.
  The Web is an information space , not a programming space.
  I imagine that developers were approached with the question “can you build an API?” And this is what they did.
  But the question was wrong. It should have been: “ can you add machine access ?”
  
  severo @severo PUBLIC DOMAIN
Écrire un commentaire