2012-10-19 12 views
16

Obecnie mamy stronę internetową, która została stworzona przy użyciu Django. Teraz chcielibyśmy stworzyć natywną aplikację na iOS, która korzysta z tego samego zaplecza, więc nie musimy ponownie koduować całej rzeczy. Z mojego rozumowania wynikają dwie alternatywne trasy:Aplikacja na iOS z Django

1) Bezpośrednie wywoływanie adresów URL Django, które następnie wywołuje funkcję. W ramach tej funkcji utwórz HTTPResponse, z zakodowanymi danymi JSON i odeślij je.

2) Utwórz usługę REST z serwera Django z czymś takim jak Tastypie. Jednak oprócz wykonywania prostych wywołań GET do obiektu, nie widzę sposobu, w jaki możemy wywoływać funkcje niestandardowe w naszych modelach Django z TastyPie. Czy możemy to zrobić?

Uważam to zaskakujące, że nie ma wiele informacji na temat spożywania usługę internetową z iOS z istniejącymi backendów jak Django lub RoR. Na przykład, wiem, że instagram używa Django, ale w jaki sposób komunikują się z iOS do swoich serwerów ?!

Wielkie dzięki!

Odpowiedz

8

Obecnie pracuję nad aplikacją na iOS dla iPhone'a, z Django/Tastypie na zapleczu. Wykonujemy zarówno 1, jak i 2. Zasoby są oferowane w stylu REST (po uwierzytelnieniu) za pośrednictwem Tastypie, a wszelkie niestandardowe wywołania funkcji (na przykład tworzenie nowego użytkownika) są obsługiwane przez views.py na różnych punktach końcowych REST, który zwraca JSON.

+1

Jaka jest wydajność? A także ... dlaczego nie skorzystałeś z opcji 1, jeśli wciąż jej używasz ?! Dzięki jeszcze raz! – abisson

+1

Zgadzam się z @ sampson-chen, robimy to samo. Mamy interfejs REST z technologią tastypie, a inne metody są wykonywane za pomocą niestandardowych usług RPC. – clopez

+1

Czy możesz wyjaśnić, jak działają niestandardowe usługi RPC? Pracuję nad czymś podobnym i chcę się upewnić, że przestrzegam pewnych standardów w zakresie uwierzytelniania i ponownego wykorzystania. – Mutant

4

Kiedy powinieneś spróbować użyć zwykłego sposobu robienia czegoś zamiast odkrywania koła. Biorąc pod uwagę, że REST jest standardowym stylem architektury oprogramowania dla systemów rozproszonych i działa bardzo dobrze podczas pracy z obiektami/obiektami.

Jeśli korzystasz z interfejsu API w interakcjach z jednostkami, zalecane jest używanie interfejsów REST. Na pytonie masz Tastypie lub nowszą Django Rest Framework, która wykonuje prawie całą pracę. Jak zaproponowałeś w 2)

Jeśli masz interfejs API, w którym wchodzisz w interakcję z usługami, takimi jak login, powinieneś zbudować usługę RPC, zasadniczo funkcję zdalnego dostępu, jak wyjaśnisz na 1).

Zazwyczaj na niezawodną aplikację zwykle trzeba korzystać w obie strony. I TAK, można to zrobić. Zgadzam się z @ sampson-chen, robimy to samo. Mamy interfejs REST z technologią tastypie, a inne metody są wykonywane za pomocą niestandardowych usług RPC.

Wydajność w naszym przypadku jest nadal dobra, ale w dużej mierze zależy od metod, które wywołujesz w swoich usługach, na przykład zapytania DB. Masz wiele sposobów na zwiększenie szybkości, na przykład za pomocą Selera do kolejkowania ciężkich zadań.

Mam nadzieję, że to pomaga.

0

Interfejsy API usługi REST są bardzo przydatne, ale ograniczają się do wykonywania operacji GET, POST, PUT, DELETE, które są wykonywane na zasobach. Może to utrudnić wyrażanie innych typów działań, takich jak wysyłanie wiadomości e-mail. Istnieje kilka sposobów, znalazłem sobie z tym poradzić w ciągu Django/tastypie:

  1. generować żądanie PUT/łata na istniejącym zasobem, ustawienie flagi, które umożliwia backend wiedzieć, aby wywołać akcję. Wykrywanie, czy flaga została ustawiona, można wykonać wewnątrz funkcji obsługi sygnałów post_save (użyj funkcji django-model-utils FieldTracker, aby sprawdzić, czy zmieniono pole z Fałsz na True); pomaga to również upewnić się, że logika aplikacji działa tak samo poza Twoim interfejsem API REST (np. zmiany za pośrednictwem strony administratora, zadania związanego z selerem, widoku opartego na HTML lub powłoki Python).

  2. Utwórz zasób inny niż ORM (np./ api/v1/email /) i zastąpić metodę post_list(), wywołując tam swoją funkcję.

  3. Utwórz nowy podrzędny zasób (/ api/v1/myresource/send /).