ios django restkit tastypie

Aplicación de iOS con Django



restkit tastypie (3)

Así que actualmente tenemos un sitio web que fue creado usando Django. Ahora, nos gustaría crear una aplicación iOS nativa que use el mismo backend, por lo que no tenemos que volver a codificar todo. Desde mi entendimiento, hay dos rutas alternativas:

1) Llame directamente a las URL de Django, que luego llama a una función. Dentro de esa función, cree una respuesta HTTP, con datos JSON codificados y envíela de vuelta.

2) Crea un servicio REST desde el servidor Django con algo como Tastypie. Sin embargo, aparte de hacer llamadas GET directas a un objeto, no veo cómo podemos llamar funciones personalizadas en nuestros modelos Django de TastyPie. ¿Podemos incluso hacer eso?

Me sorprende que no haya mucha información sobre el consumo de un servicio web de iOS con backends existentes como Django o RoR. Por ejemplo, sé que Instagram usa Django, pero ¿cómo se comunican desde iOS a sus servidores?

¡Muchas gracias!


Actualmente estoy trabajando en una aplicación de iOS para iPhone, con Django / Tastypie en el backend. Hacemos tanto el 1 como el 2. Los recursos se ofrecen al estilo REST (después de la autenticación) a través de Tastypie, y cualquier llamada a función personalizada (por ejemplo, la creación de un nuevo usuario) es manejada por views.py en varios puntos finales REST, que devuelve JSON.


Cuando pueda, debe intentar utilizar una forma común de hacer algo en lugar de reinventar la rueda. Dado esto, REST es un estilo estándar de arquitectura de software para sistemas distribuidos y funciona muy bien cuando se trabaja con entidades / objetos.

Si tiene una API en la que interactúa con entidades, se recomienda utilizar interfaces REST. En Python tienes Tastypie o el nuevo Django Rest Framework que hace casi todo el trabajo. Como propones en 2)

Si tiene una API en la que interactúa con servicios, como un inicio de sesión, debe crear un servicio RPC, básicamente una función con acceso remoto como se explica en 1).

Normalmente necesitará ambas formas en una aplicación robusta. Y sí, es posible hacer eso. Estoy de acuerdo con @ sampson-chen, estamos haciendo lo mismo. Tenemos una interfaz REST con tastypie, y otros métodos se realizan con servicios RPC personalizados.

El rendimiento en nuestro caso sigue siendo bueno, pero depende principalmente de los métodos a los que llama dentro de sus servicios, por ejemplo, una consulta de base de datos. Tiene muchas formas de mejorar la velocidad, por ejemplo, usar Celery para hacer cola en trabajos pesados.

Espero eso ayude.


Las API REST, aunque son muy útiles, lo limitan a las acciones GET, POST, PUT, DELETE, que se realizan en los recursos. Esto puede dificultar la expresión de otros tipos de acción, como enviar un correo electrónico. Hay algunas formas que he encontrado para manejar esto dentro de django / tastypie:

  1. Emita una solicitud PUT / PATCH en un recurso existente, configurando una bandera que le avise a su servidor para activar una acción. Se puede detectar si se estableció una bandera dentro de los manejadores de señales post_save (use django-model-utils FieldTracker para ver si un campo se cambió de Falso a Verdadero); esto también ayuda a asegurarse de que la lógica de su aplicación funcione de la misma manera fuera de su API REST (como los cambios a través del sitio de administración, una tarea de apio, una vista basada en HTML o el shell de Python).

  2. Cree un recurso que no sea ORM (por ejemplo, / api / v1 / email /) y anule el método post_list (), llamando a su función allí.

  3. Como se mencionó en otra parte, cree un recurso subordinado (/ api / v1 / myresource / send /).