I sometimes hear about making web-site fully API based, meaning that even in browser the page is constructed based on API endpoint and practically nothing else.

One of the benefits I see in this is that when you will make smartphone application you already have API that works and tested. And in case you need to change something you can change desktop and mobile app practically at the same time(with some tweaks maybe).

Maybe I somehow misunderstood the idea, but I have some questions about the whole viability of it. Unfortunately I couldn't find any good article on this topic(which is strange, maybe it is because this is not what people do and I just misunderstood it completely).

Just for example to be clear about the scope lets say we are building social-network-ish site.

  1. For mobile development API is the default way, but for desktop it seems to be overkill for me. I am used to Django framework and you can do page rendering quite easily - browser sends GET or POST request with parameters and you render a response page, can not be easier. But if I decide to use API on desktop browser then instead of simple request I need to construct JSON, send it to API endpoint, deserialize it and then render a response. And unlike with usual way, where I can generate very complex response in one step - with API endpoints I may actually need to use several endpoints to generate desktop webpage with lots of content, i.e. I end up sending multiple API requests. So by using API for everything on desktop version of the site I increase the number of requests to the server and also the amount of code needed. Yes, I will save time developing mobile app, but at the cost of increased bandwidth and decreased robustness, which is not alright in my opinion. Maybe I don't get something, would be nice if somebody can explain.
  2. Does it really make sense to do desktop version relying on API endpoints everywhere? I've seen people talk about it sometimes, but I have never seen any examples or big articles about it, which suggests to me that maybe this is indeed a stupid idea and I am wasting my time even thinking about it. Does anybody really make big desktop website where every little thing is tied to API endpoints? I may be not very experienced, but as far as I know on it is usually small API calls when they are helpful, but not the whole structure relies on API(unlike in mobile apps). So should I stick to usual development and leave API almost exclusively to mobile apps?
  • do you mean a single page app? ie one basic html file with the javascript setup and then everything else done via json and a templating framework? i think this is pretty much standard these days
    – Ewan
    Commented Oct 5, 2016 at 10:58
  • @Ewan, no, not single page app. Think stuff like Youtube or Facebook - many many pages with lots of content on it. So not a SaaS thing. Commented Oct 5, 2016 at 11:00
  • 1
    facebook is a single page app
    – Ewan
    Commented Oct 5, 2016 at 11:02
  • @Ewan, oops, never actually was interested, it looks like it is not(with direct links and stuff). But anyway, I am wondering about not single page app. Commented Oct 5, 2016 at 11:07
  • Why not a Progressive App? developers.google.com/web/progressive-web-apps Commented Oct 7, 2016 at 12:38

2 Answers 2


It sounds like you are talking about a 'single page app'

This term is used to refer to websites where all or most of the actions you take are accomplished via client side javascript AJAX calls, which retrieve json, convert that json to html and update the page

rather than:

Having the browser request a new html page which is returned and shown by the browser, discarding the old page.

Although I agree there are downsides to this approach, it is now the de facto standard architecture for website design. The simple reason being that AJAX gives a clearly better user experience over page loads.

Several javascript frameworks such as react and angular are available to make this approach easy to implement.

So, most 'single page apps' are NOT all done on a single page. Admin pages, Settings etc are in my experience usually split off, in to what is effectively a separate 'single page app'. ie you have a Admin.html which also uses angular or whatever and has a set of apis to do its in page functionality.

This makes it easier to separate out the concerns and address some problems that single page apps tend to have with authentication.

The user experience is not really affected, because changing between these sections of the site is not something they do often and is seen as a 'big step' with the entire page changing.

However, you should consider carefully where this approach is sensible. having some forms submit via standard http and some via your js framework would seem to me not to add any benefit. If you are using a framework, stick to it and use it for everything. If you are doing old skool html, stick to that. combining both approaches will simply mean you get the downsides of both.

  • I understand the idea behind angular and single page, but if I want to specifically separate pages(with some AJAX calls for UX on them, but not everything on single one page) - does it make sense to base everything on AJAX and API inside these multiple pages? Example: there is "edit profile" page and separate "create new group" page. Is there sense to implement functionality(e.g. displaying and submitting forms) via API and not via simple form submit with link and parameters(not JSON at all)? Commented Oct 5, 2016 at 11:19
  • 1
    @RemcoGerlich, I already decided that I am not making it single page app, but I can still use API to write to database, read from database, etc. inside of those many pages! Which in theory saves time developing API for future mobile app, but it makes code for browser version much more complex than it needs to be. Commented Oct 5, 2016 at 11:39
  • 1
    @ScienceSamovar: yes, but that's a question "is using some Ajax on a web page a good idea?", your question is about fully API based. If you make everything API based, then you need to have everything on the page constructed by Javascript anyway, and you might as well have a single page app. Yes it makes the browser javascript much more complex, but the backend less complex -- you're moving the user interface entirely into javascript instead of half in Django and half in the browser. Commented Oct 5, 2016 at 11:43
  • 1
    For the record, I don't think this is the "de facto standard". I've worked for many different companies and I've consulted with many government agencies, and I've never worked on a web site built this way. Maybe it's the new de facto standard in some segments of the industry or for some class of applications.
    – Jay
    Commented Oct 5, 2016 at 14:08
  • 1
    This is not the "de facto standard" cause SEO on single page app is doable but still painful and ugly. Commented Oct 5, 2016 at 15:46

It makes sense to have a shared API behind every way of accessing your system. Behind this API you can handle repeating concerns, like what entities you have and how they are loaded from the database, or how to handle user authentication and authorization. You should aim for the difference between two different clients, like mobile and desktop, to be restricted to their actual differences, with no duplication of code.

However, this does not mean you must reuse the web services for all the front-ends. Here you have several options:

  • A shared API, a set of classes, that is wrapped once into web services and once into (server-side) web pages
  • Use the web services as API, but call them from inside the server to render server-side web pages
  • Use the web services as API, and call them from the client.

Returning to your question:

Does it really make sense to do desktop version relying on API endpoints everywhere?

Yes, it does make sense to have your desktop version rely on the same API as your mobile version. No, it does not have to be in the form of web service endpoints.

Elaborating on these choices, you may be interested in the backends-for-frontends pattern.

  • Thanks for article link, I really thought of something like this with exception that desktop UI would work in completely different way in backend(using pure python without API endpoints). Now I get that this is probably is not the best solution and it would be good to utilize the same API, but with different BFF. Thanks for another useful answer, upvoted. Commented Oct 5, 2016 at 16:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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