Public API for Codidact

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.

All power to your elbow!


No one’s mentioned it here yet but just to beat them to it:

You can have an API and still use razor pages! +1 to the API idea


Yes, there will be a public API in Codidact - it’s not decided whether or not it’s MVP yet, but I’m leaning towards yes.


So, welcome…

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.

1 Like

Hi, @BhargavRao!

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

I’ll be sure to remember that :wink: