Consider calling requests from your movieapi class and handling exceptions there

[ryaustin]

          here we can make several small improvements for robustness, readability and maintainability of your code:

• error handling when calling requests - you might consider making this call to requests a part of your MovieApiUtils class so that you are not constantly dealing with exception handling in your views.
• Type hints, It’s generally recommended to use Dict from typing for clarity and consistency, especially when sharing code with others. small 'd' still works but it's one of those things that might cause a head-scratcher if someone else with a older version of python runs your code.
• You want to check if your response is valid before requesting JSON. here you can use response.raise_for_status() because It helps ensure that your code gracefully handles situations where an HTTP request fails.

_Originally posted by @ryaustin in https://github.com/kjcioffi/django-movies/pull/14#discussion_r1633923512_

[ryaustin]

From a class design perspective, do you forsee any issues calling your endpoints from the movieapi class? You might create one function to manage all calls using requests.

Imagine the MovieAPIUtils is the official python SDK to interact with TMDB. What key design decisions would make that would make your tool enjoyable to use.

[kjcioffi]

I am blocked on this issue. I understand what you mean by the context provided, however, based on your second comment you seem to be suggesting I use a single function to manage all calls.

Based on this information, I take it that:

• Design-wise, it makes more sense to use a single function for all API calls.
• This function would benefit from being static.

But I'm finding myself needing direction with:

• Properly navigating exception handling in the utility class so they aren't embedded in the views.
• Should these API calls return a Response or would you recommend JSON?
• How could I use one function to call any endpoint?
  • Parameterize the function via the use of positional arguments for information such as the endpoint and then use kwargs to pass any additional information?

[ryaustin]

Hey Kevin, were we able to address this adequately enough during our session yesterday to move forward? As a review:

Class
   CONSTANTS 
    ...

   def init
       ...
       self.authenticate

   def authenticate
       # place any logic around authentication and potential errors/ exceptions here

   def get(url, params/kwargs)
       #any exception handling around get requests occur in this function
       response = requests.get(url, params, self.header)
       # check the response status, is it a 200? does it have json?, are there errors?
       return response

   def movies_currently_playing(*args, **kwargs)
     url=f"{self.BASE_URL}/specific_endpoint" 
     #pass kwargs directly to the get function or for more robustness perform any transformations, cleanup on the kwargs then pass on in a dict called params. This may not be necessary so is up to you.
     params={} #add any specific params here
     return self.get(url, params)

   def other_endpoint(*args, **kwargs)
       #same pattern as above
       return self.get(url, params)

In a nutshell, all of the work to consume various endpoints happens in the class. This pattern puts most of your effort in the class. In your view, you will most likely define the class in the global scope and call the endpoints in your context functions and passing in any specific params required by the individual functions.