I would like to know if there is an interest to add a public API to the Codidact MVP. Some advantages of having a public API are:
Users can utilize the public API and build their own small applications that would help Codidact. This includes slack connections, mail feeds and so on.
There can be extensions, like mobile apps that are built on top of the API.
Users can consume data from the API to get necessary status info about their posts.
Given the fact that the backend is already exposing a REST API, it wouldnât be that hard to create another public endpoint.
Some not so good reasons would be:
There is already a lot of work to do, adding a new heavy feature would be difficult and taxing.
The project is already open source, and contributors can directly add new features instead of using the public API to build their own.
Some users (like me) are more attracted to a site due to the fact that there exists a public API and they can consume that to create nice things. Would it be possible to add a public API? Atleast a read-only version would be really helpful. (I would certainly like to chip in during the design phase of the public API, if there is going to be one)
I donât know whether you can see a banner at the top of your post that reads âThis is the first time BhargavRao has posted â letâs welcome them to our community!â and I donât feel I have any business to be the one to welcome you (as a recent joiner myself and, I regret, with little I can contribute at this stage) but I have been enormously impressed by your contributions elsewhere and am very glad indeed you have made an appearance here.
What is a public API â that would be the web (i.e. HTTP) interface, wouldnât it?
And the web interface is defined by â itâs identical to â the set of URLs aka âroutesâ, which the server supports for GET and/or POST requests, is it not? And those GET requests usually return HTML pages â but maybe youâd call that a UI though, not an API.
Perhaps an API then, couldnât or wouldnât that be identical to the UI â the same URLs except returning naked data in JSON format â perhaps depending only on the Accept header in the HTTP request? Or is an API something different?
Technically, an API can be âanything accessible from another systemâ. But practically speaking, and based on typical web usage, I believe what we are referring to here as âPublic APIâ includes the following specific attributes:
No special credentials required.
Note though that we might want to, for rate limiting, tracking or other reasons, require basic credentials (essentially linking the API usage to a nominal user) for âany API usageâ, and certainly require credentials (enforcing all Trust Level privileges/restrictions) for anything that causes an update to the database (see note below) or to read Deleted records or other limited-access information.
Data is returned in a standard, more-machine-readable-than-human-readable format.
Typically this is either JSON (my preference for a bunch of reasons) or XML. But technically an API can return a full HTML web page. If you write a âweb scraperâ then you are essentially using ordinary web pages as if they were API functions.
An API in this context means GET (read)/POST (add)/PUT (update)/DELETE (delete). But there is some variance (I recently had some that I made POST recently instead of GET due to technical complications that made GET a potential security issue) .
But before-the-web (and still today on native applications inside most systems), an API could be a function call to a defined memory location, a software interrupt, putting a file in a particular location for it to be accessed by another process or almost any other inter-process communication method you can dream up. But here (and general âweb APIâ) we are talking about HTTPS GET/POST/etc.
Given what the OP and @ArtOfCode wrote, I wondered, âWhat is that âpublic APIâ except simply the URLs which support getting HTML and posting form data?â
And whether that API is âeasyâ, because, itâs simply (nothing more than) the same URLs already implemented for HTML, except returning data in JSON format instead of rendered into an HTML template.
It is actually quite a bit different, though generally far simpler. For example, a âcommunity home pageâ HTML might include:
Some user-related info at the top (name, link to profile page)
User-specific content (e.g., unread notifications - yes they may dynamically load if Javascript is enabled and the page âsitsâ for a while, but initially they would probably come in on page load)
List of the ânâ most recently updated questions with title, vote count, tag names, first few lines of content.
Sidebar including links to various items of interest (determined based on community & user preferences and active âstuffâ), links to âMetaâ or other places, etc.
Header including links to other âCategoriesâ
Footer including links to privacy policy, etc., link to Instance home page, etc.
On the other hand, an API query for âhome page questionsâ might be more like:
Pass in the number of questions, else default to the same ânâ as the HTML page.
Return JSON object containing the full content of the Questions.
With a SPA you could have a boilerplate HTML blob and then use AJAX to load in all the components (user info, notifications, question summaries, etc.) But there are a bunch of reasons (which I happen to agree with!) why we are not designing this as an SPA but rather rendering complete pages server-side.
Weâll have a public HTTP-based RESTful API, thatâs for sure. The question is whether or not itâll be released as part of the minimum viable product, as Art said. I donât have a strong opinion in either direction.
Oh, and
I would certainly like to chip in during the design phase of the public API, if there is going to be one
