Bonjour,
 
le sondage porte sur le type d'API que vous préférez utiliser dans vos activités de développement.
 
Quelques précisions sur les réponses possibles:
 
- SOAP / XML prend de l'XML en entrée (en POST) et sort de l'XML en sortie. L'API un service SOAP / XML est "autodescriptif" et permet la génération de "stub" dans beaucoup de langages
 
- REST / JSON prend du json (en GET / POST / PUT / DELETE, ca dépend) en entrée et sort du JSON en sortie, en faisant varier les codes de retour HTTP
 
- HTTP FORM / XML prend des paramètres de formulaires en entrée (le genre de paramètres qu'on récupère en PHP via $_GET ou $_POST) et sort du XML
 
- un package tout fait va vous permettre d'instancier une API et d'appeler l'API via des méthodes. Que ca soit des appels HTTP derrière vous est parfaitement égal. En java il peut s'agir d'un .jar, en php un module PEAR ou composer

Pas très populaire ...

1- non trop verbeux,mais l'avantage de l'autodocumentation est quand même sympa
 
2- oui, si bien documenté  
 
3- non : les inconvenient du 1 , sans les avantages
 
4- uniquement si le cout des requetes http est problématique.

- SOAP, parce qu'en .Net ça va super vite à réaliser, exposer, et surtout consommer grâce au côté auto documenté. Par contre évidemment c'est lent et verbeux, XML oblige.  
- JSON parce que c'est rapide, léger et puissant. Mais le côté "documentation du contrat" manque encore faute de norme, même s'il y a moyen de gruger ou de bricoler (json2csharp, etc).  

Pour le côté documentation du REST JSON, on peut tenter une approche via SWAGGER et générer des stubs et la doc, mais c'est moins carré que SOAP. Et en plus les stubs nécessitent des versions plutôt récentes des langages/environnements.

Je pense qu'il est assez aisé de dire que JSON a pris le pas sur la majorité des autres possibilités...

Protobuf ou thrift ftw  

Intéressant ce thrift!

Mais un peu complexe.

Protobuf ça a l'air sympa et performant (format binaire, champ indexés plutôt que nommés, etc) et c'est dispo sur pas mal de langages donc malgré que ça ne soit pas une norme c'est interopérable.
Par contre comme c'est binaire on peut oublier le logging "bas niveau" et c'est pas idéal pour du client léger vers serveur mais plutôt serveur à serveur.

Mais non

Qu'est ce que tu entends par logging bas niveau? Je suis pas sur pour thrift mais en protobuf il y'a tout ce qu'il faut pour logger les valeurs de façon human readable  

 
Le soucis c'est qu'il y a d'avantage de prérequis que du REST classique ... et beaucoup de développeurs travaillent dans des environnements relativement obsolètes ou mal administrés.
 
Au moins en faisant du REST, si les stubs se génèrent pas ou que le dev peut rien toucher dans son environnement, il peut toujours bricoler un truc vite fait.
 
 
 
 
Sinon, j'aime beaucoup la doc d'API d'OVH ( https://eu.api.ovh.com/console/#/allDom#GET ).

 
+1

Je n'en doute pas, vu que c'est super basique comme besoin. Mais ça veut dire "transformer le machin binaire indexé numériquement" en "pseudo truc à chaîne lisible avec des champs nommés", ça implique donc des traitements en plus et éventuellement des subtilités entre le message réel et sa version "convertie".  
Alors qu'un json tu le logges quand il arrive et basta, pas de questions à se poser.
Ca ne retire rien aux autres intérêts du format binaire indexé pour ce qui est de la légèreté .

 
non, si tu utilises les stubs generes tu touches jamais aux donnees binaires, uniquement aux objets deserialises, du coup typiquement tu peux logger tes objets directements sans rien faire (En java le toString override fait ce qu'il faut, en c++ faut appeler DebugString() pour du human readable)

... Du coup tu logges bien l'objet final et pas la trame initiale, c'est ce que je sous entendais par "bas niveau" plus haut.
En SOAP, JSON ou autre format texte la trame elle même a du sens et pour débugger des cas complexes ça peut aider de l'avoir sous sa forme brute.

 
Pour le .Net, on propose maintenant un wrapper swagger qui génère une aide contextuelle dans Visual Studio.
 
On a même publié le wrapper sur Nuget, qui est du coup très facilement utilisable en visual basic, C#, asp.net ...
 
Je trouve ce système de package (Nuget) remarquable de simplicité, Maven est une usine à gaz à côté    
 
 

Tu parles de NSwag ?
Oui nuget c'est extrêmement bien foutu, même si parfois selon la version du framework ciblée par les assemblies qui y font appel on a des petites bizarreries, et aussi j'ai un peu de mal à adhérer à la gueule qu'a pris nuget dans VS2015