Session 4 - APIs and intro to data visualization

[luisesanmartin]

Some notes:

• The API session includes slides with a no-code introduction and then how to use APIs programmatically in Python. The objective is that participants understand what are APIs, how to code a simple API client, and how to use client libraries
• For data vis, keep in mind that it's an introductory session that assumes familiarity of the participants with the most common types of plots. The idea is to show how to produce those plots in matplotlib and seaborn, comparing the difference in their syntax. I'm not sure if I should add a couple more sections covering line plots, histograms, and simple maps. Let me know what you think of that. I also wanted initially to include examples using altair to provide the option of a library that is heavily based on the grammar of graphics, but then declined in order not to make the introductory session too complex
• My sense is that both materials in total will take 100-120 minutes to be covered. That will leave 45-30 minutes for the exercises
• It doesn't say explicitly, but I'm thinking that the "challenges" parts are the exercises for the last part of the session so that they last for 2.5 hours in total. I'm still pending to add more challenge exercises in data vis

[weilu]

@luisesanmartin I've reviewed the slides and the notebook on APIs. It's looking good.

I think the API section is missing introduction of fundamental concepts such as: What's HTTP? including different part of an URL: protocol (http vs https), domain, path, query params. Then there's HTTP request and HTTP response. For example http requests can be made independent from any programming language or any package – perhaps demo making an HTTP request from the browser (like you did in the slides) and/or curl, or postman. In covering requests perhaps also consider explaining a bit of the relevant HTTP request headers, e.g. Content-Type, Accept, different requests methods – most notably GET and POST which are likely the two they might use for data fetching; then with POST it might be natural to introduce request payload and some common formats like JSON and/or XML, which also can be used for response payload. Then in covering HTTP responses, it might be useful to talk about a few common response status codes, 200, 404, 403, 429, 500 etc

I believe these are important concepts to introduce as they are fundamental to interacting with the internet programmatically. They are also programming language independent and library/package independent. The material doesn't need to be comprehensive but should be sufficient to give the audience the power and knowledge of the proper terms which they can understand (e.g. in documentations) and use later when they apply it in exercises and projects.

Other comments:

• perhaps consider using a json formatter chrome extension so json outputs are more readable/presentable in your slides? I use this one: https://chrome.google.com/webstore/detail/json-formatter/bcjindcccaagfpapjjmafapmmgkkhgoa
• consider including some pandas function e.g. read_json, read_xm in the notebook before introducing requests? Since pandas was introduced in session3 and the students might feel less intimated with a familiar library which has some support to read directly from APIs? Might also be fun to run into some pandas' limitations which gives you a bridge/reason to introduce requests ;)
• consider introducing some best practices when hitting APIs e.g. request rate limiting, CORS might be relevant when people try to do this in colab? Optional of course depends on time limitations etc.

[luisesanmartin]

@weilu thanks a lot for the review, you include lots of thoughts and a perspective that had not occurred to me. I included some of your suggestions but not all. In general, I think explaining more about HTTP adds complexity for the session that is not strictly necessary for an introduction of how to work with APIs. I did include more content and an explanation about requests and responses that makes how to use requests and the response object type clearer.

In data vis, my idea for the session is that it should be more of a live demonstration than a "lecture" type like APIs is, so I'm not including exercises in the session. I'm thinking this because APIs (and the concepts introduced in previous sessions) are probably quite new for participants while data vis might be more familiar for them. Still, I think this is already a lot to cover in one session and I'm thinking of giving more importance and time to APIs.

[luisesanmartin]

let me know if you have any thoughts, I'm adding the exercise solutions for the APIs part tomorrow