Phase 1: Add generic HTTP request

[aleksa-krolls]

See parent issue #887 for details.

[martalovescoffee]

@hunterachieng could you please add an estimate to this issue?

[josephjclark]

Adjustments to the design:

• change the existing common request helper so that it does not use instanceUrl
• Add to the existing common request helper an option called baseUrl, which gets forwarded directly into the common request helper on request options
• The existing HTTP operations should be modified to pass instanceUrl as baseUrl - ie, they'll each pass in the option.

So far, we haven't changed any behaviour from the user's point of view. Hopefully some tests will break, and we can fix them

Next, in http. add a new request operation which just calls out to the common request helper. It does NOT pass a value for baseUrl

The utils.request signature is probably going to get very long (too many parameters) so you may want to refactor it to request(state, method, path, options), where options is an object like { query, body, baseUrl }

My only doubt about this is: what about pagination? Should the generic request util really handle pagination? The fhir API will want to do it differently. Maybe that's something we can worry about later.

[aleksa-krolls]

@josephjclark if the get() in http adaptor does not handle pagination, then we don't need to worry about it for openmrs http.get(). If it does handle pagination, why not add the same pattern here?

[josephjclark]

@aleksa-krolls the http adaptor does not handle pagination because pagination on every HTTP service is a bit different.

We have implemented "generic" pagination support for for OpenMRS already. But by "generic" we really mean for the Rest API. Other modules, including fhir, could use different pagination semantics. In practice it's probably just fhir we need to worry about.

What I think we'll need to do when we get to the fhir APIs is:

• update the common request helper with no pagination
• add a rest API helper which calls common and adds pagination (and feeds the other rest API functions)
• add a fhir API helper which calls common and adds pagination (and feeds the other FHIR API functions)

It's just a question of moving all the code to the right place so its nice and tidy.

[aleksa-krolls]

ok cool, so as I said... if http does not handle pagination... then no need to here. Just wanted to be consistent, and I'm board with all of your points.

Great if later down the line we want to add enhanced support for the fhir api, but at minimum next week I want to be able to implement the common request helper (and all good if no pagination).