HEEDLS-672 Learning Hub API client

[livzorn]

JIRA link

HEEDLS-672
HEEDLS-672

Description

Created the Learning hub Api client and associated view models. Configured user secrets to store the API key, and each developer will have to add it to their user secrets file locally.

Screenshots

None

---

Developer checks

(Leave tasks unticked if they haven't been appropriate for your ticket.)

I have:

• Run the formatter and made sure there are no IDE errors.
• Written tests for the changes (accessibility tests, unit tests for controller, data services, services, view models, etc)
• Manually tested my work with and without JavaScript. Full manual testing guidelines can be found here: https://softwiretech.atlassian.net/wiki/spaces/HEE/pages/6703648740/Testing
• Updated/added documentation in Swiki and/or Readme. Links (if any) are below:
  • doc_1_here
• Updated my Jira ticket with information about other parts of the system that were touched as part of the MR and have to be sanity tested to ensure nothing’s broken.
• Scanned over my own MR to ensure everything is as expected.

[AlexJacksonDS]

I think there are some improvements that could be made to tidy up the url handling.

[AlexJacksonDS]

I'm pretty sure there must be a better way to do all this query string construction without using a bunch of string concatenation and interpolation.

[livzorn]

I initially used QueryHelpers.AddQueryString to add the query strings, but this method only accepts string values, not StringValues values, so it was impossible to add the query strings dealing with enumerables. Steve suggested I create the query strings manually, but if you can think of a better way, please enlighten me. It does feel a bit icky

[AlexJacksonDS]

Might be worth having a chat about/pairing on some ideas to sort out the query strings. I think it certainly should be possible to simplify some of the steps by being a bit smarter about whether we are appending & to the strings or not and making better use of the fact we've got IEnumerables we can use to join/split etc.

[DanBloxham-sw]

Looking good overall, just a couple of minor changes.

[DanBloxham-sw]

Given that an empty collection of ints could be passed in, and we know that we will get empty lists backs, we can probably bypass the unnecessary call and just return the model with the empty lists (or maybe null if you think that might be better)

[AlexJacksonDS]

We should keep the return type correct (so no null), but I'm not sure whether we should short circuit the API call or not. I kind of feel like the API client should always call the API, and perhaps any calling method should be deciding whether it should call the API or not.

[DanBloxham-sw]

Yeah, that sounds reasonable, it can stay as it is.