Alright folks, I was recently involved in other LIMS integrations and one pattern that is very much alike is a “click this functionality to enable the equivalent API” approach. Basically, by module, you decide what can be exposed or not. And then, by role or by user (or lab, of all of that), you grant consuming rights.
It got me thinking “heh, STARLIMS used to do that with the generic.asmx web service”. RunAction and RunActionDirect anyone?
So, that’s just what I did, for fun, but also thinking that if I’d go around re-writing routing and scripts for every single functionalities, that would be a total waste of time. Now, don’t get me wrong! Like everything, I think that it depends.
You can (and should) expose only bits and pieces you need to expose, unless your plan is to use STARLIMS as a backend mostly and integrate most (if not all) of the features to external systems (those of you who you want a React or Angular front end, that’s you!).
So, if you’re in the later group, take into consideration security. You will want to set the RestApi_DevMode setting to false STARLIMS’ web.config file. This is to ensure that all communication is hashed using MD5 and not tampered with. Then, of course, you’ll check https and all these things. This is out of scope, but still worthy of note.
Once that’s done, you need 2 pieces.
- You need to define a route. Personnally, I used the route /v1/generic/action . If you don’t know how to do that, I wrote and article on the topic.
- You need a script to do all of this! Here’s the simplified code:
:PROCEDURE POST;
:PARAMETERS payload;
:IF payload:IsProperty("action") .and. !Empty(payload:action);
:DECLARE response;
response := CreateUdObject();
response:StatusCode := 200;
response:Response := CreateUdObject();
response:Response:data := "";
:IF payload:IsProperty("parameters") .and. !Empty(payload:parameters);
response:Response:data := ExecFunction(payload:action, payload:parameters);
:ELSE;
response:Response:data := ExecFunction(payload:action);
:ENDIF;
:RETURN response;
:ELSE;
:DECLARE response;
response := CreateUdObject();
response:StatusCode := 400;
response:Response := CreateUdObject();
response:Response:message := "invalid action/parameters";
:RETURN response;
:ENDIF;
:ENDPROC;
In my case, I went a little bit more fancy by adding an impersonation mechanism so the code would “run as”. You could add some authorization on which scripts can be ran, by who, when, etc. Just do it at the beginning, and the return a 403 forbidden response if execution is denied.
Yeah, I know, this is not rocket science, and this is not necessarily the most secure approach. In fact, this really opens up your STARLIMS instance to ANY integration from a third party software… But, as I mentioned in the beginning, maybe that’s what you want?
NB: I used DALL·E 2 (openai.com) to generate the image on the front page using “STARLIMS logo ripped open”. I had to try!