-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HTTP API #2
Comments
I also think it's great. For example, how about splitting the EDN file beforehand as follows?
👍 Pros.
👎 Cons.
|
Great point! I like this idea, as for most clients it'd be quite convenient to work with that. I don't think we need to a smaller granularity than this (e.g. breakdown for see alsos, notes, etc), as the EDN file for each symbol shouldn't be very big and clients can fetch it process it locally additionally. |
OK, I'll fix codes to generate them 😄 |
I have one point to discuss. Some filesystems are case insensible, so it couldn't write EDN files separately.
@bbatsov Do you have any ideas? |
I'll have to think about this. Another approach would be to have a different convention for data types, as those are the things with capitalized names. How many such cases are there in total? I assume not many, right? |
Yeah, there are only 5 cases as follows.
|
I've been thinking lately that it'd be great if we exposed a simple HTTP API to query directly our ClojureDocs EDN export. This would simplify the lives of clients a lot, as they won't have to deal with keeping a local copy of the data and will be able to fetch some data even without Orchard or cider-nrepl.
I guess the simplest API would be - clients request the docs for a symbol and get everything we have about it. A more polished API would allow for clients to specify they want only part of the data for some symbol (e.g.
:see-alsos
). @liquidz What do you think?The text was updated successfully, but these errors were encountered: