First of all, this question is far more different other \'public api questions\'
ID: 647363 • Letter: F
Question
First of all, this question is far more different other 'public api questions' like this: Should a website use its own public API?, second, sorry for my English. You can find the question summarized at the bottom of this question.
What I want to achieve is a big website with a public api, so who like programming (like me) and likes my website, can replicate my website's data with a much better approach (of course with some restrictions).
Almost everything could be used by the public API.
Because of this, I was thinking about making the whole website AJAX driven.
There would be parts of the API which would be limited only to my website (domain), like login, registering.
There would be only an INTERFACE on the client side, which would use the public and private API to make this interface working.
The website would be ONLY CLIENT SIDE, well, I mean, the website would only use AJAX to use the api.
How do I imagine this?
The website would be like a mobile application, the application only sending a request to a webserver, which returns a json, the application parses it, and uses it to advance in the application. (e.g.: login)
My thoughts:
Pros:
The whole website is built up by javascript, this means I don't need to transfer the html to the client, saving bandwidth. (I hope so)
Anyone can use up the data of my website to make their own cool things. (Is this a con or pro? O_O)
The public API is always in use, so I can see if there are any error.
Cons:
Without Javascript the website is unusable.
The bad guys easily can load the server with requesting too much data (like Request Per Second > 10000), but this can be countered via limiting this with some PHP code and logging.
Probably much more work
So the question in some words is: Should I build my website around my own api? Is it good to work only on the client side? Is this good for a big website? (e.x.: facebook, yeah facebook is a different story, but could it run with an 'architecture' like this?)
Explanation / Answer
If I understand your question correctly, your question is, "should I write a fat client?"
The answer is yes, if you want what a fat client provides you, which is a very high level of interactivity with the end user. This level of interactivity is provided by a fat client, because you don't have to constantly make round trips to the server to get new pages. If your app does not require that level of interactivity, then you may not need a fat client.
Your pro about the web server saving bandwidth by only sending data and not HTML does not seem compelling. Unless you have millions of users, this level of bandwidth is never going to be a problem, and if you do have millions of users, I'd say it's a good problem.
Generally speaking, the more of your app that you can keep on the server, the easier it will be to write, and the more secure it is going to be. Note that your server can still utilize a public API.
Examples of possible candidates for fat clients
Real-time game
Real-time, interactive business dashboard
Examples of possible candidates for thin clients
Online Survey Form
Billing Address Form (may include some AJAX for looking up city from the zip code, etc.)
Related Questions
Navigate
Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.