Application iOS avec Django
Donc nous avons actuellement un site web qui a été créé à l'aide de Django. Maintenant, nous aimerions créer un natif iOS app qui utilise le même back-end, afin de ne pas avoir à re-coder l'ensemble de la chose. De ma compréhension, il y a deux possibilités:
1) Appeler directement Django Url, ce qui appelle une fonction. Dans cette fonction, créer un HTTPResponse, avec codées les données JSON et l'envoyer en arrière.
2) Créer un Service REST de l'Django serveur avec quelque chose comme Tastypie. Toutefois, en dehors de faire straight-forward REÇOIS des appels pour un objet, je ne vois pas comment on peut appeler des fonctions personnalisées dans notre Django Modèles de TastyPie. Pouvons-nous le faire?
Je trouve étonnant qu'il n'y a pas beaucoup d'informations sur la consommation d'un service web à partir d'iOS avec l'existant backends comme Django ou RoR. Par exemple, je sais que instagram utilise Django, mais comment font-ils pour communiquer à partir d'iOS à leurs serveurs?!
Merci beaucoup!
source d'informationauteur abisson
Vous devez vous connecter pour publier un commentaire.
Je suis actuellement en train de travailler sur une application iOS pour iPhone, avec Django /Tastypie dans le backend. Nous le faisons à la fois 1 et 2. Les ressources sont offertes RESTE de style (après authentification) via Tastypie, et tous les appels de fonction (par exemple, la création d'un nouvel utilisateur) sont traitées par l'views.py à différents RESTE des points de terminaison, qui renvoie du JSON.
Quand vous pouvez vous devriez essayer d'utiliser d'une manière commune de faire quelque chose plutôt que de réinventer la roue. Étant donné que, REST est un style d'architecture logicielle pour les systèmes distribués et il fonctionne très bien lorsque vous travaillez avec des entités ou à des objets.
Si vous avez une API où vous interagissez avec d'autres entités, il est recommandé d'utiliser des interfaces REST. Sur python vous avez Tastypie ou la plus récente Django Repos Cadre qui fait presque tout le travail. Comme vous le proposons en 2)
Si vous avez une API où vous interagissez avec les services, comme une connexion, alors vous devez créer un service RPC, essentiellement une fonction d'accès à distance comme vous l'expliquez sur 1).
Normalement, vous aurez besoin de deux façons sur une application robuste. Et OUI, il est possible de le faire. Je suis d'accord avec @sampson-chen, nous faisons le même. Nous avons une interface REST avec tastypie, et d'autres méthodes sont effectuées à la coutume des services RPC.
La performance dans notre cas, c'est encore bon, mais dépend principalement de la méthodes que vous appelez à l'intérieur de vos services, par exemple, une base de données de la requête. Vous avez beaucoup de moyens pour améliorer la vitesse, par exemple à l'aide de Céleri à la file d'attente de travaux lourds.
Espère que cela aide.
Api REST, bien que très utile, vous limite à GET, POST, PUT, DELETE les actions qui sont effectuées sur les ressources. Cela peut rendre difficile à exprimer d'autres types d'actions, telles que l'envoi d'un e-mail. Il existe quelques façons que j'ai trouvé pour gérer cela dans django/tastypie:
Question d'un PUT/PATCH demande sur une ressource existante, un indicateur qui permet à votre backend sais pour déclencher une action. Détecter si un indicateur a été défini qui peut être fait à l'intérieur de post_save les gestionnaires de signaux (utiliser django-modèle-utils FieldTracker pour voir si un champ a été modifié à partir de la valeur False à True); cela permet aussi de s'assurer que l'application de la logique de fonctionnement est le même à l'extérieur de votre API REST (tels que les changements via l'interface d'administration du site, du céleri, un HTML en fonction de la vue, ou le Python shell).
Créer un non-ORM Ressource (par exemple, /api/v1/email/) et remplacer la post_list() la méthode, l'appel de votre fonction.
Comme mentionné ailleurs, créer un subordonné de ressources (/api/v1/myresource/envoyer/).