Search code examples
djangorestarchitecturetastypie

REST app architecture

I am working on a RESTful application, which goal is to allow user to track his results, progress and performance in sport activities.

I want to create two or more clients for this app:

1) web client

2) mobile client ( iOS / Android )

I am writting it in django using tastypie app and I wonder if I should make web client in the same application, which will provide the RESTful api or should I leave it as a pure REST service and build separate web client, which will contact it via the api?

As for now I don't see any drawbacks of making both in one, but I am not an expert in programs with such an architecture, so I am looking for some advise with argumentation behind it.

Solution

  • It is not easy to answer to this as it depends a lot on what kind of service you are building.

    Approach 1: Traditional Django app + API

    Here your Django-app and the tastpie API share common data models but present them differently. One using Djangos templates and views and the other using tastypie.

    Pros:

    • Building a traditinal web service is relatively easy and well understood problem
      • Django provides a lot of tools for this

    Cons:

    • There is no gurantee that the API presents the same functionality as the web service
    • You have to maintain two different ways to interact with your data.

    Approach 2: API only + JavaScript webapp that uses the API

    There is only one interface to the service via the tastypie API. The web client is built separately using javascript tools like backbone.js and backbone-tastypie.

    Pros:

    • You gurantee that the 3rd party developers can build a service with the same functionality as your web service (see dogfooding).
    • Works pretty nicely if your service is more of an application than a collection of pages.

    Cons:

    • Client side JavaScript tools are not as good as Djangos (for example, templating).
    • Client side rendering of templates only happens after most of the resources are loaded.
      • First pageload is slow
    • Pre-IE9 browsers won't work without trick, IE9 may need tricks
    • You really need to mind about browser caches
    • SEO is not as straightforward as with traditional web service.

    Approach 3: API only + call the API from Django views

    Pretty much same as Approach 1 but instead of using your models directly you call the tastypie resources internally.

    Pros:

    • You can still use most of the Django tools.
    • You mostly use the same API as potential 3rd party developers

    Cons:

    • I do not know how much overhead this incurs.