2010-08-09 22 views
0

Ok Je suis en train de programmer un moyen d'interface avec Grooveshark (http://grooveshark.com). En ce moment j'ai une classe Grooveshark et plusieurs méthodes, on obtient une session avec le serveur, un autre obtient un jeton basé sur la session et un autre est utilisé pour construire des appels api au serveur (et d'autres méthodes l'utilisent). En ce moment, je l'utilise comme si .... Remarque utilise tordu et torsadé tidefer dansConception d'une interface vers un site Web api

g = Grooveshark() 
d = g.get_session() 
d.addCallback(lambda x: g.get_token()) 
## and then something like.... ## 
g.search("Song") 

Je trouve ce sens unpythonic et laid, même après l'initialisation de la classe, vous devez appeler deux méthodes d'abord, ou bien les autres méthodes ne fonctionnera pas. Pour résoudre ce problème, j'essaie de faire en sorte que la méthode qui crée les appels api prenne en charge la session et le jeton. Actuellement, ces deux méthodes (les méthodes de session et de jeton) définissent des variables de classe et ne retournent rien (bien, aucune). Donc ma question est, est-ce qu'il y a un design commun utilisé pour l'interfaçage avec des sites qui nécessitent des jetons et des sessions? De plus, le jeton et session sont récupérés à partir d'un serveur, donc je ne peux pas les exécuter dans la méthode initialisation (comme il le ferait bloc ou ne peut pas être fait avant un appel api est fait)

+0

Je pense que le titre de votre question est un peu trompeur. Je l'ai lu et je pensais que vous étiez en train de concevoir une interface utilisateur pour une API existante (quelque chose comme api.jquery.com), et non une API. –

Répondre

3

Je trouve ce sens non pythonique et moche même après l'initialisation de la classe vous devez d'abord appeler deux méthodes ou les autres méthodes ne fonctionneront pas.

Si oui, alors pourquoi ne pas mettre __init__ de la partie get_session dans votre classe? Si cela doit toujours être fait avant toute autre chose, cela semblerait logique. Bien sûr, cela signifie que l'appel de la classe retournera une instance encore inutilisable - ce qui est inévitable avec la programmation asynchrone, la commande événementielle ... vous ne "bloquez pas jusqu'à ce que l'instance soit prête à l'emploi".

Une possibilité serait de passer le rappel à effectuer en tant qu'argument à la classe lorsque vous l'appelez; un plus Twisted-normal devrait être Grooveshark être une fonction qui renvoie un différé (vous ajouterez au différé le rappel à effectuer, et l'appelez avec l'instance comme argument lorsque cette instance est finalement prête à être utilisée) .

+0

Ok merci, donc en gros c'est une usine asynchrone? Les get_session et get_token sont aussi en contact avec un serveur donc ce ne sont pas des fonctions que je peux utiliser dans n'importe quelle vitesse – Zimm3r

+0

@ Zimm3r, bien sûr que non - c'est pourquoi je suggère soit une approche simpliste (qui va à l'encontre de Twisted ;-) de passer le rappel directement quand vous appelez la classe, ou, mieux, de ne pas appeler la classe mais une fonction d'usine qui renvoie un différé (si c'est ce que vous voulez dire par "async factory", alors c'est certainement un; . –

+1

"Bien sûr, cela signifie que l'appel de la classe renverra toujours une instance encore inutilisable, ce qui est inévitable avec la programmation asynchrone et événementielle ..." Pas nécessairement. Si vous souhaitez que la configuration de la session soit transparente, vous pouvez la rendre transparente. Le fait que les autres méthodes (comme la recherche) renvoie déjà un différé signifie que l'appelant ne remarquera probablement même pas si le résultat doit attendre la fin de l'installation de la session. En d'autres termes, la recherche et les autres méthodes devraient simplement attendre sur le get_session Deferred qu'ils devraient soit appeler en interne, soit initier __init__. –

0

Je recommande fortement de regarder le Facebook graph API. Ce n'est pas parce que vous avez besoin de sessions et d'une authentification que vous pouvez créer une API REST propre. Facebook utilise OAuth pour gérer l'authentification mais il existe d'autres possibilités.