2010-04-22 4 views
4

On m'a demandé d'aider la société d'un ami à faire apparaître une application web. J'ai très peu de temps et j'ai accepté à contrecoeur la demande, à une condition. Comme la plupart de la logique se poursuit dans le back-end, j'ai suggéré que je terminerais le backend complet seulement, permettant à un développeur frontal de simplement s'interfacer avec mon backend.Méthode client RPC la plus simple en PHP

Je prévois de faire le back-end en Java EE ou Python (avec Pylons). Cela n'a pas vraiment d'importance à ce stade. Je prévois d'avoir mon système dorsal complètement prêt et testé, de sorte que mon apport sera à peine nécessaire une fois mon travail terminé.

Je sais qu'ils ont un programmeur PHP, mais pour autant que je puisse dire, il est un vrai débutant. Je veux qu'il interfère essentiellement avec les services de mon backend de la manière la plus simple possible, sans aucun moyen de le «bourrer». C'est essentiellement une application CRUD seulement.

Je pourrais implémenter le backend comme accessible via un service web tel que XML-RPC ou SOAP. Même une API RESTful pourrait être possible.

Cependant, mon objectif principal est de faire quelque chose que le programmeur PHP "noob" peut facilement interfacer sans se confondre. De préférence, je ne veux même pas lui parler parce que j'ai généralement un emploi du temps extrêmement chargé, et faire des «appels de soutien» n'est pas quelque chose que je suis prêt à faire. Quelle approche devrais-je choisir? J'accueillerais n'importe quelles suggestions et entrées!

Répondre

5

Je choisirais personnellement une API REST, probablement avec une réponse JSON. SOAP et XML peuvent être un peu lourds pour des services simples, et même le développeur web le plus novice comprend le concept d'accès à une URL de base, même s'il ne gêne pas le concept global de REST. Il y a des myriades de façons de travailler avec les URL en PHP, donc je suis sûr qu'ils seraient capables de trouver quelque chose, même si c'était un travail de hack au lieu d'un paquet client sympa.

Je choisirais probablement aussi le codage et le décodage JSON, car c'est assez simple, alors que l'analyse XML peut être un peu plus décourageante.

Je voudrais également écrire au moins une documentation de base sur le service, quels que soient les formats que vous choisissez. Sinon, vous ne pourrez pas échapper aux appels de support. Votre consommateur cible doit avoir une référence des actions à distance qui lui sont accessibles, ou une méthode pour découvrir ces actions. Il vous faudrait probablement 10 minutes pour obtenir un exemple de code quand il est prêt, et ces 10 minutes pourraient vous faire économiser beaucoup d'emailing.

+0

+1 sur REST, +2 sur JSON, +3 sur document le .... maintenant je vous dois 5 points ... – Javier

+0

Bonne idée. Je suis convaincu d'aller avec une API RESTful sur celui-ci. Comme pour la documentation de base, nous aurons un document d'exigences avec des maquettes de captures d'écran et tout, donc il ne peut pas se tromper avec ça. Comme pour JSON vs params sur les chaînes de requête GET/POST, je pense que le dernier, je vais devoir y penser .. Merci! –

2

Vraiment aller avec une mise en œuvre comme au repos, et retourner la sortie formatée de chaîne de requête. N'oubliez pas que php va transformer des variables de type tableau en un tableau du côté php.

Prenez une chaîne de requête pour vos paramètres

Entrée: p1=v1&p2=v2....

Sortie: output1=var1&output[0]=var2;output[2]=var3

L'accès à ce en php est alors un simple

<? 
    $request['myparam1'] = param; 
    ... 
    $webService ="http://path.to.service?".http_build_query($request); 

    parse_str(file_get_contents($webService),$response); 

    // response is now an array with you response parameters in it 
    // $response['responseParam1'], reponse['responseParam1'] etc 
?> 
+1

il est plus facile et plus prévisible des deux côtés d'utiliser simplement JSON – Javier

+0

Merci Byron. Je suis toujours coincé entre décider si aller pour parse_str et JSON. Je vais devoir y réfléchir. –

2

Been there, done that.

Backend dans Django, interface en PHP par un entrepreneur «nous faisons des pages». J'ai monté une API de type REST en utilisant JSON, leur ai fourni deux fonctions PHP de 5 lignes pour accéder à mon service en tant que magasin de valeurs-clés. Après quelques faux départs (où ils ont essayé un schéma artificiel et redirigé au lieu d'utiliser les fonctions que je leur ai envoyées), ils l'ont obtenu et tout s'est bien passé après cela.

+0

Je pense que j'ai décidé d'adopter la méthode JSON maintenant. :) –

Questions connexes