search

cmneal26 / Tech-Writing-Project

Class repository
2 stars 1 forks source link

Find Us An API That Doesn't Use An API Key #18

Closed ghost closed 2 years ago

ghost commented 2 years ago

The OpenWeatherMap API is simple and easy to use, which is great. However, it requires an API key to use. If we do end up fetching data on the GitHub Pages website live for this first project, we would have to make that API key available in order to make the successful request. (whether we do this depends on the results of this issue: https://github.com/cmneal26/Tech-Writing-Project/issues/16)

So what's the problem? We can't just commit the API key to our public repo. Then anyone could find it, and charge thousands of dollars to the account tied to the API key, by spamming the API and using that key. Usually, there is some process for 'supplying' values to the website (values such as the API key) in a more secure fashion. However, we aren't familiar with Eleventy. To be safe, and make sure we can complete our first project on time, we can use an API that doesn't require a key, and so avoid having to handle this additional complexity.

So, the goal of this issue is to search online, and find a public API that you can make requests to which we can use for this first fetch tutorial.

cmneal26 commented 2 years ago

It looks like a bunch of these don't require a key:

ghost commented 2 years ago

Whichever API you like works. Just paste a link to it under the GitHub Issue here.

cmneal26 commented 2 years ago

Thoughts on this one?

(https://random-d.uk/api)

ghost commented 2 years ago

awesome, I like it. Why? I like the fact that it has multiple endpoints (it gives you multiple kinds/ways of retrieving data from the api). Why is it good to have multiple endpoints for a creative project like this? Then in the context of the markdown document when we access the api data/also at build if we want, we can do different and cool things.

@cmneal26 If Tim gives you the okay, choose a version of the api (like v2), make a list of the specific data and endpoints you might like to see in the this first project doc, or have available on one of the pages on the site. And have that in mind for our Friday meeting. Then close out this issue (move from life cycle stage "Incomplete" to ticket life cycle stage "Complete" in GitHub Issues.

When you move a ticket from incomplete to complete, ask yourself this question, "Are there any concluding thoughts that I should put here, so that when someone views the issue it will help them understand the functionality and context?" If the answer is no, you don't have to put any comment before closing. If the answer is yes, put whatever comment you think is relevant. in the issue as a comment before closing.