Bonjour,

Je vais devoir pour les besoins de ma boîte créer une API pour notre site internet...
Seulement je ne me suis jamais frotté à ce genre de choses et j'aimerais donc partir sur de bonnes base

Donc mon api auras deux types "d'actions" possibles:

• Du listing d'infos sans besoin d'être connecté
  Là je pense que ça ne doit pas être très dur, simplement proposer le choix du format de sortie (xml,json,etc...), il n'y a pas vraiment d'interaction avec les futures applciations développées autour de l'API
• Des actions où l'on doit être loggé sur notre site.
  Et c'est là que c'est le plus difficile je pense :/ Comment lier une application externe avec notre site? j'ai déjà vu par exemple OAuth, mais je n'ai aps du tout poussé plus loin.

Pour commencer je vais essayer de me concentrer sur les actions basiques (sans connection).
J'ai vu par exemple cette api http://www.zijob.fr/api.html qui me parait sympa dans le fonctionnement, donc je pourrais par exemple pour donner une liste de voitures avoir une url du genre:

monsite.com/api/voitures/list

?

Bon c'est très flou, je ne sais pas trop par où commencer!
Si vous aviez des retours d'expèrience sur le sujet?
merci d'avance

la question est simple.

comment proposer à l'utilisateur de l'api et ceci le plus simplement possible, les informations et action nécessaires.

Euh, je ne sais pas trop ce que vise cette question
Le "comment" porte sur le format des données? sur la manière de les obtenir?

Pour l'instant j'ai modifié un petit peu le schéma de l'url d'accès à l'api il ressemblerais à ça:

api-module[-action[.format[.encodage]]]

apiurl/objet/action c'est mieux

et décline les actions pour l'encodage et le format

genre:

apiurl/voiture/listjson
apiurl/voiture/listxml
apiurl/voiture/add
apiurl/voiture/modify
apiurl/voiture/delete

le principe d'avoir une série d'objets métiers auquel on applique les actions de listage/ajout/modification/suppression c'est quasiment un design pattern (en fait c'est probablement un design pattern mais je n'ai pas la terminologie sous le coude)

si tu as une identification

apiurl/auth/login (param login/password, renvoit status+éventuellement id, droits, groupes ou autre trucs relatifs à une gestion user)
apiurl/auth/logout

Hey,

Merci pour le retour, alors déjà effectivement je voulais garder les slash pour l'url, mais je fait du rewrite là-dessus, et je n'arrive pas à faire passer les slashs dedans :/
Donc en attendant de trouver une solution, je commence avec les tirets

Par contre je ne vois pas encore comment récupérer des paramètres GET/POST venant d'une application externe...
Dans le cas d'une action d'ajout de voiture, il faut pouvoir spécifier son modèle et sa couleur pour l'exemple...
Donc on a une url Mais il faut faire parvenir les données, donc en POST je pense que c'est faisable, mais ça oblige les concepteurs d'applications à utiliser dans le cas de php par exemple curl...
Et je ne sais pas par exemple si il existe des choses similaires sur des applications iphone, flash ou autre...?

Hey,

Merci pour le retour, alors déjà effectivement je voulais garder les slash pour l'url, mais je fait du rewrite là-dessus, et je n'arrive pas à faire passer les slashs dedans :/
Donc en attendant de trouver une solution, je commence avec les tirets

Par contre je ne vois pas encore comment récupérer des paramètres GET/POST venant d'une application externe...
Dans le cas d'une action d'ajout de voiture, il faut pouvoir spécifier son modèle et sa couleur pour l'exemple...
Donc on a une url

Code : Tout sélectionner

apiurl/voitures/add

Mais il faut faire parvenir les données, donc en POST je pense que c'est faisable, mais ça oblige les concepteurs d'applications à utiliser dans le cas de php par exemple curl...
Et je ne sais pas par exemple si il existe des choses similaires sur des applications iphone, flash ou autre...?

c'est vrai que post>get pour transvaser un nombre de données suffisant, pour ce qui est des gens qui vont attaquer ton api, tu peux tout t'autoriser du moment que tu files des sample de code client, typiquement les clients seront php uniquement ou c'est hétérogène?, si c'est hétérogène et que le montant de donnée est pas trop important (pas de binaires pas de listes interminables de 10 000 éléments) alors soap reste une option tout à fait viable, bien que personellement je lui préférerais une solution basée sur un encodage serialize/unserialize (plus concis en texte pur donc plus légé sur le réseau).

Yep,

c'est vrai que post>get pour transvaser un nombre de données suffisant, pour ce qui est des gens qui vont attaquer ton api, tu peux tout t'autoriser du moment que tu files des sample de code client, typiquement les clients seront php uniquement ou c'est hétérogène?, si c'est hétérogène et que le montant de donnée est pas trop important (pas de binaires pas de listes interminables de 10 000 éléments) alors soap reste une option tout à fait viable, bien que personellement je lui préférerais une solution basée sur un encodage serialize/unserialize (plus concis en texte pur donc plus légé sur le réseau).

Pour ce qui est des utilisateurs, je n'ai pour l'instant qu'un developpeur d'une application iphone, et je ne sais pas du tout en quoi il va le faire.
Soap m'a l'air d'une soution interessante, mais j'avoue que je ne comprend pas tout :/
En tout cas, je n'aurais pas vraiment de gros volumes de données...

Yep,

c'est vrai que post>get pour transvaser un nombre de données suffisant, pour ce qui est des gens qui vont attaquer ton api, tu peux tout t'autoriser du moment que tu files des sample de code client, typiquement les clients seront php uniquement ou c'est hétérogène?, si c'est hétérogène et que le montant de donnée est pas trop important (pas de binaires pas de listes interminables de 10 000 éléments) alors soap reste une option tout à fait viable, bien que personellement je lui préférerais une solution basée sur un encodage serialize/unserialize (plus concis en texte pur donc plus légé sur le réseau).

Pour ce qui est des utilisateurs, je n'ai pour l'instant qu'un developpeur d'une application iphone, et je ne sais pas du tout en quoi il va le faire.
Soap m'a l'air d'une soution interessante, mais j'avoue que je ne comprend pas tout :/
En tout cas, je n'aurais pas vraiment de gros volumes de données...

il le fera en cocoa probablement, et il aura plus que certainement un support de soap