Local Internal API URL Structure Change - Add Site Parameter to URL

OpenEMR Development
, , ,
1

TL;DR; Should we change the internal api urls to use a site parameter to be consistent with the rest of our fhir/standard api urls.

So I finally am working on a project that is using the OpenEMR internal api where you don’t have to authenticate and instead use the API CRSF token that is populated in the session. Got that all working by looking at the example in tests/api/InternalAPITest.php.

However, I found that the URLs that we are using for the internal api do NOT take in a site parameter in the url which threw me off completely as its different to how we handle FHIR and our authenticated standard api.

For example a patient request in FHIR / standard api is as follows for the default site installation:
/apis/default/fhir/Patient - FHIR api
/apis/default/api/patient - standard api

But with the internal api usage using the apicsrftoken header the url is
/apis/fhir/patient - FHIR api
/apis/api/patient - standard api

I find this very confusing. I get that we can grab the site from inside the session and don’t really need it in the URLs but I really think for documentation, developers, and consistency we should keep the URLs the same.

I’d like to suggest we change this up, but I’m also concerned about legacy usage for people (and core code) who may have built against the URLs without the site parameter. I would think we could change it up so we can be backwards compliant for the next couple of releases with a deprecation warning.

If there is a reason why we need to keep the URLs this way and not add the site parameter, I’d like to know.

1 Like
2

I have a HTTP client I wrote thinking internal and FHIR client however, nobody used it and I pulled most of it’s demo stuff and was working on refactoring it out in the few places it is used.
Still may not solve your issue but I thought I’d take the opportunity to point out I wrote a HTTP client!:slight_smile: src/Common/Http/oeHttp.php

Couldn’t you check the route for the presence of the site then resolve to default if not there.

2 Likes
3

As far as being backwards compatible I think that’s the case, just default to ‘default’ if its not there.

4

Definitely agree with doing this. I think it is basically that way since the original api endpoints didn’t have site in the path.