Project

General

Profile

Project management #14175

Project management #14174: Rayonnement des web-services

Définir format de description des web-services

Added by Benjamin Dauvergne almost 3 years ago. Updated almost 3 years ago.

Status:
Nouveau
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
30 Nov 2016
Due date:
31 Jan 2017
% Done:

0%

Patch proposed:
No
Planning:
No
Demande du club utilisateur:
No

History

#1 Updated by Thomas Noël almost 3 years ago

Avez-vous des choses contre http://json-schema.org/ ? (le projet semble avoir un peu repris...)

#2 Updated by Frédéric Péters almost 3 years ago

Avez-vous des choses contre http://json-schema.org/ ? (le projet semble avoir un peu repris...)

Je ne suis pas sûr de voir où vient cette suggestion mais généralement je ne pense pas nécessaire de commencer par une description formelle du format et je trouve qu'on va plus vite en commençant par cas après cas donner en exemple la description qui correspondrait.

Exemple : Passerelle annoncer à Combo qu'un service "factures" est disponible :

{
  "type": "invoices",
  "title": "Factures logiciel famille",
  "base_url": "https://passerelle.example.net/family/test/regie/" 
}

Et ça serait déjà un grand pas. Pour reprendre des notes de l'eocamp :

=> décrire les API de façon "fonctionnelle", ie qualifiée, ie son type :.
  • "cette BASE_URL propose une API compatible «newsletters»".
  • "cette BASE_URL propose une API compatible «factures»"
  • "cette BASE_URL propose une API compatible «datasources»"
  • famille
  • appairage
  • agendas
  • SIG (aka nominatim & référentiels d'adresses)
  • SMS
  • gestion de panier

Ensuite, quand il faudra décrire de manière générique des API pour l'action "appel webservice" de w.c.s., il sera temps de décrire davantage et peut-être qu'un schéma deviendra alors utile. Mais pour le moment, "dictionnaire avec trois clés, type, title, base_url", on peut faire sans.

Also available in: Atom PDF