> Will api sub domain return S-Expressions with data like most API send JSON?

We looked at the problem last year and earlier this year, and GraphQL
would seem to be a good fit for the API. If we go with something else,
we'll be re-inventing ad hoc solutions to many of the problems that it
has already solved in a generic way.

An alternative S-expression syntax for making GraphQL queries would be
nice. The query results are ordinary JSON, which we could map to
ordinary S-expressions in the same way that SRFI 180 does.

> What kind of data you want to expose with the API?

IMHO almost everything that anyone wants to include in there. We can add
things piecemeal.

> It would be nice if the api use CORS[1] headers, so you can use the api from
> Browser's JavaScript. I think it would be nice example for my Scheme
> interpreter, how easy is to interact with S-Expr API. There will be not much
> of use of the API in browser if it's restricted and you need to use
> server proxy script just to use it.
>
> [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

Sounds like a good idea. It would definitely be useful to access the API
from in-browser JS. For starters, much functionality on other scheme.org
subdomains could be implemented by querying the API either client-side
or server-side.