Thoughts on JSON structures / schemas / templates

[Nick Renders]

Thank you for all the input.

I would just like to clarify: we are not setting up our own REST 
service. We are simply making HTTP requests from Omnis Studio to an 
external REST server. I would like the make this implementation as 
flexible as possible, because I expect many different iterations 
(versions) of the REST service will be released. I want to stay away 
from any hard coded JSON, so that when an update to a request is 
necessary, there is no need to update the Omnis library.

Cheers,

Nick


On 12 Jun 2019, at 13:24, Nick Renders wrote:

> Hi List,
>
> I am thinking about implementing some calls to a third party REST 
> Service into our Omnis Libraries, but before I paint myself into a 
> corner, I wanted to see if anyone had any thoughts on / experience 
> with the subject.
>
> The service is your typical HTTP REST server:
> - there are different endpoints (URI) we can call, with different 
> (CGI) parameters
> - each request has some mandatory and custom headers
> - a request can have a body (JSON)
> - if the request is successful, a JSON is returned as result
>
>
> The goal is to set up an environment that can be entirely customisable 
> by the Omnis user: the requests (endpoint, parameters, header, body) 
> are defined somewhere and are automatically generated with the correct 
> data when sending a request. If any updates need to be done to the 
> request (new parameters, nodes added or removed from JSON, ...), the 
> user can do this in a GUI without having to change any Omnis code.
>
> Basically, it means that there are some JSON templates with links to 
> variables that will populate the nodes. I have been thinking on what 
> might be the best way to define these JSON templates / structures, and 
> so far I have come up with three possibilities:
>
> 1) save an "empty" JSON as a character field.
> 	PRO: easy and fast to code and implement
> 	CON: hard to define how the nodes should be populated (which 
> variables to use)
>
> 2) save a list / row variable as a binary field.
> 	PRO: easy and fast, e.g. with the OJSON.$jsontolistorrow function
> 	CON: still not sure how to link variables (for instance, an integer 
> column cannot hold the variable's name)
>
> 3) use schema classes (and save as binary field?).
> 	PRO: the Description column can be used to specify variable names or 
> other options
> 	CON: lots of array / object nodes means lots of (sub-)schemas
>
>
> Currently, I am favouring the third approach, but I am reluctant to 
> create so many schema class. On top of that, it also means that any 
> changes are made in the library directly, so there will be a need to 
> somehow save those in a centralised database as well.
>
>
> Does anyone have any thoughts or tips on this? Has anyone done 
> something similar, defining JSON structures and populate them with 
> data? Any feedback is very much welcome.
>
>
> Thanks,
>
> Nick Renders
> _____________________________________________________________
> Manage your list subscriptions at http://lists.omnis-dev.com
> Start a new message -> mailto:omnisdev-en at lists.omnis-dev.com