This repository has been archived by the owner on Sep 24, 2022. It is now read-only.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Create API_overview.md #22
base: main
Are you sure you want to change the base?
Create API_overview.md #22
Changes from 1 commit
595a561
91c4764
b15766c
6a9e3d7
6a4a270
17adeea
9d49920
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@fineon
Hey Ian,
I wanted to get your opinion on this opening statement. Technically, an API is rather an interface that ensures two parties (for example a server and a browser) can communicate than a data store.
What we built is a JSON file that we can query - but I think the way to fetch an entry is by using normal HTTP methods, right?
My bottom line here is: It doesn't sound technically correct to say that the API itself stores the data. I wonder how we can word it differently so it is more technically accurate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm what about
The Chonologue API is an open source interface that provides astronomical and temporal events
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am okay with the 2nd sentence. It is technically correct.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you both for your input! I'm still new to the field and I find myself mixing concepts so is great to have more experienced eyes catching these inaccuracies.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor suggestion: The query can be done via an HTTP client, that's correct.
Can you clarify what you want to express with "visualize"? I am guessing that you mean a graphical representation, like on our website (which a web browser would be a suitable HTTP client as you mentioned).
Another very small nitpick: Instead of highlighting Chrome here, I would choose a more neutral phrase like: "... you need an HTTP client, for example, a web browser. "
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, your assumption is correct. My justification for why I talk about "visualization" in the overview is to situate the API within the context of "The Chronologue" project. First I answer the question "what does the Chronologue API do? It stores astronomical events data that you can query" and then I extend this a bit further "you can visualize these events on the Chronologue website".
In my mind, If I just leave it at "The Chronologue API stores astronomical data..." the reader, especially scientists, might be left with a thought of "and then what?"
I hope it makes sense : )
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In our Slack conversation, Ian answered this question. At the moment, the API sends the response to the Chronologue website. I therefore assumed that the only way to use this data is to visualize the event it contains. Please correct me if this is wrong. Is it possible for the user to query astronomical data, receive it via the Chronologue website and not visualize it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Context: At some point, we need to create a contribution guide, similar to what the template team has: Template Contribution Guide
For now, I would place this section probably at the end of the document, since the main goal of the document is to get an overview, first. After people have a good idea of what they are dealing with, they might be happy to contribute.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure thing!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe that you can make GET requests also without going through the request for new recording, so I would just link to that document in a related links section at the bottom. :)
CC: @fineon What do you think: Do we need to hand out API keys to make GET requests?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would put this information into either the overview or higher up in main features. :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for creating a graphic! It might be a good opener for the section.
The only thing I find hard to understand is what we mean by "visualization request".
I would assume that more technical people are using the Chronologue API, so they might not need a visualization (that's what the website already does).
I am guessing that a reader of this document might want to know what requests they can make against the API, for example GET requests or POST requests. We can also highlight that for GET requests, you don't need to be authorized, but for POST, you might need a key. I'm just thinking out loud here, maybe @fineon has some ideas as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I changed the name to "Request for new recording" to be consistent with the terminology Peter used in his document.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if we need subheadings.
We could also structure it a bit more lean like:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sound ok to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Love these use cases! 👍