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.
- 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.
- 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?
Best Answer
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.