I am designing an API with django and its rest framework (and I am already not sure if it worth the hassle to version it or not).

I totally know the iOS and Android apps will call the API, get a token (maybe with expiration I need to read a bit more about it) and then use this token inside every subsequent calls to be able to authenticate.

But my main question is : should my web interface use the API ?

Because it does not seems very practical, I rather see myself using sessions and cookies and having the backend render templates passing data through it than getting a token and doing AJAX calls for everything.

  • 2
    dogfooding – user40980 Nov 7 '15 at 21:47
  • I already saw this term in few posts and I am all about using my API if that makes sense (less work for me and more consistency). But let's say a visitor comes to my website, go to the login page (/login) and put some credentials. On the server side what should I do ? Call /api/auth passing username/password and then ? (this is where I am really lost) – soueuls Nov 7 '15 at 22:03
  • (Disclaimer: I have never done either of these things, I've only used the traditional route) I think the two API routes are a "single page website" where you never refresh the page and it acts like an app. Or where your display layer (server side) calls your API (also server side) rather than using traditional function calls – Richard Tingle Nov 7 '15 at 22:13

These are arguments for creating SPA that convince me:

  1. Do you want you application to be usable offline? Take a look at how gmail behaves when there is no connection. Functionality is very limited, but, it's still usable. Things can be taken one step further since HTML5 brings many options for client-side storage. Server-side storage may be treated as only backup and synchronization component. It makes the client fault-tolarant.
  2. How fast do you want your application to respond after each click? According to research done at Google, users feel the application as fast and responsive if there is a feedback after less than 200ms. If something may last longer, an indication of long-lasting operation should appear (spinner or progress bar). This things are doable only in SPA.
  3. Why do you want to treat one type of clients in a special way? Implementing server-side code just for one client type will probably result in more code written. An issue of simplicity of system's architecture and probably even DRY.
  4. API is a well defined boundary that slows down software entropy. Sole fact that there is an API to be designed forces a very good practice of actually designing the software. Lack of well defined boundaries may (in time) lower maintainability of a system, because of accidental inter-dependencies being added. This becomes significant in bigger code bases.
  5. Moving presentation logic to the client reduces resources needed on the server. It may reduce cost of the project significantly, depending on the technology at use, size of the project, and how much the project is about presentation. I've seen a project in which half of server-side resources were consumed by presentation logic and session storage (it used JSF extensively).

So if none of above matters in your project and knowledge of JavaScript is limited in the team, it may be a good idea to stick to the old school server-side template rendering.


Your question motivated me to write a blogpost about SPA.

  • Another point you may want to add is that, until the site picks up momentum, using your API yourself may be the only use it gets. When your site is really attracting attention is not the time to discover your API is hard to use, or out of date. – Morgen Nov 9 '15 at 14:29
  • Yes, but your integration API should probably be different from your internal API. Not only in terms of functionality, but also security. – Maciej Chałapuk Nov 12 '15 at 8:33
  • I can see an argument for exposing only a subset of your internal api as an external api. I'm not sure I agree with it, but that's a design choice. I disagree having differing levels of security. Everything from the client is suspect, so why should the security be relaxed for either? It's not terribly difficult to hijack your own session to access the the api calls of a SPA, so they should have the same level of authentication and validation as api calls from a source that's known to be external. – Morgen Nov 12 '15 at 14:26
  • Sorry for late response, @Morgen. I had to give it some thought :) I agree 100%. – Maciej Chałapuk Aug 23 at 17:30

It's a valid approach to use an API directly by the web client.

This API needs to support a way to create a user session and return a token which the client will pass with every call.

I can see the following benefits to this solution

  • All yours clients (mobile, web, external) are using the same API, which can make maintaining and scaling it easier
  • Keeping the responsibility of HTML rendering entirely on the client side, which is well supported by current javascript frameworks.

An alternative approach is make a layer on top of your web API, that does rendering, session management. I haven't done this because it seemed way more complicated than necessary.

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.