HTML REST API?

[NotionCommotion]

Here is the scenario.

I created a niche market API which provides environmental data.  The data is obtained by industrial controllers which don't monitor anything by default, and the API has additional endpoints which are used to instruct the industrial controllers to start monitoring some parameter so the API can then start storing the trend data.  The API primarily responds with JSON, however, a couple of endpoints support CSV data.

For humans/webclients to access the data, I also created a webserver application which can be added to a Concrete5 (C5) CMS.  I tried to make as many of its endpoints do nothing except receive the webclient's request, add a JSON Web Token to it which contains a unique identifier, forward it to the API using cURL, and return the response as is to the webclient.  To limit the scope which needed to be created for the C5 application, the API has endpoints to return JSON which is used by JavaScript on the webclient for client-side validation, endpoints (actually, a different domain) to return static JavaScript/CSS/etc, and endpoints to restructure the JSON data to some more suitable format.

I now am looking at creating different applications which does not use C5, but either are 100% custom or use some other CMS such as Drupal, etc.  While I tried to limit the scope implemented on the C5 application, I have much more than I desire and will need to duplicate much for any future application.  The primary scope I would like to remove from the webserver application relates to the HTML views and consists of templates which create HTML from JSON, the JavaScript which interacts with the HTML, and to a lesser degree controllers to determine the type of view (i.e. a list of records or one specific detail record).

While the API will only be managed by myself, the intent is that the C5, 100% custom, etc webserver apps are installed and managed by others. 

Ideally, there is some existing Composer package for transforming JSON to HTML which is CMS agnostic, however, I don't know whether such exists.  Also, while not 100% necessary, ideally this functionality could exist on my server and not the individual web application's server.

Whether I build it myself or use some existing package, I expect it will need to do something like the following:

The various webserver apps will have some routing table to proxy the request either to my JSON API server (complete) or my new "HTML API Server" (remaining discusses this portion).

This HTML API server would generate the content either by making a cURL request to the main JSON API, or better yet since likely located on the same server have routing functional to make direct calls to the JSON API's methods, and return something like the following:

{
    "html": "<div>Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Pharetra massa massa ultricies mi quis hendrerit dolor. Leo integer malesuada nunc vel risus commodo viverra.</div>",
    "javascript_files": [
        "https://resources.myserver.com/someFile.js",
        "https://resources.myserver.com/someOtherFile.js"
    ],
    "css_files": [
        "https://resources.myserver.com/someFile.css",
        "https://resources.myserver.com/someOtherFile.css"
    ]
}

The various applications would then take the HTML and resource files and insert them using their proprietary methods. 

EDIT.  Also, thinking of using an IFRAME, however, definitely have concerns with doing so.

My day job has nothing to do with software, however, am hoping to make it so.  Before embarking on this task, I would like to know whether some existing framework exists and if not what general strategy (organization, caching, etc) I should take to develop it.

Thanks

Edited January 18, 2021 by NotionCommotion
Added IFRAME idea

[requinix]

So what's the question? Oh, found it.

Some existing framework or strategy to do what part, exactly?

If the general problem is how to deal with multiple MVC frameworks, the answer is typically to have a code interface that does as much work as possible so that the framework endpoints can do as little as possible.
If you're asking about literally converting JSON to HTML, I think the coolest option is to forget JSON and go with XML. Because that can use XSLT to render the data however you want.

 

[NotionCommotion]

4 hours ago, requinix said:

If the general problem is how to deal with multiple MVC frameworks, the answer is typically to have a code interface that does as much work as possible so that the framework endpoints can do as little as possible.
If you're asking about literally converting JSON to HTML, I think the coolest option is to forget JSON and go with XML. Because that can use XSLT to render the data however you want.

Currently, I have custom endpoints in the C5 application which basically do two things:

1. Make a cURL request to retrieve JSON which is converted into an array, and then uses Twig along with a specific Twig template for each endpoint which creates a portion of HTML.
2. Define which JS/CSS resources should be included with the page.

Then the HTML along with the JS/CSS resources are given to the core C5 application which renders the page as applicable.

My thought was to move the functionality of creating the portion of HTML along along with the required resource paths to another server and call this endpoint instead of the one to provide JSON.  Alternatively, maybe it requests just the template and JSON data and renders it itself.

I haven't used XSLT and am just looking into it now, but don't see how it would be utilized.  At first, I thought it was some sort of template engine like Twig, but don't still think so.

[requinix]

1 minute ago, NotionCommotion said:

Currently, I have custom endpoints in the C5 application which basically do two things:

1. Make a cURL request to retrieve JSON which is converted into an array, and then uses Twig along with a specific Twig template for each endpoint which creates a portion of HTML.
2. Define which JS/CSS resources should be included with the page.

Then the HTML along with the JS/CSS resources are given to the core C5 application which renders the page as applicable.

The problem is that all of that stuff varies with usage. Each place may want different templates, or different Javascript, or different CSS.
It doesn't make logical sense to put frontend stuff into the backend.

 

1 minute ago, NotionCommotion said:

I haven't used XSLT and am just looking into it now, but don't see how it would be utilized.  At first, I thought it was some sort of template engine like Twig, but don't still think so.

XSLT is about transforming XML into something else. Like HTML.

For example, if you had XML <username>NotionCommotion</username> then you could write some XSLT which transforms <username> nodes into <span class="username"> HTML elements. It's been a long time since I've done this but the XSLT looks something like

<xsl:template match="username">
  <span class="username">
    <xsl:value-of select="." />
  </span>
</xsl:template>

(that's just a portion of the whole XSLT document, which would be handling other things as well)

Now I'm only really bringing this up because you floated the idea of a sort of "convert JSON to HTML" thing. I think it would probably be better to go with a standardized JSON format and plain ol' HTML templates.

[NotionCommotion]

1 hour ago, requinix said:

Now I'm only really bringing this up because you floated the idea of a sort of "convert JSON to HTML" thing. I think it would probably be better to go with a standardized JSON format and plain ol' HTML templates.

Thanks.  Will stay away from that rabbit hole for now.

1 hour ago, requinix said:

The problem is that all of that stuff varies with usage. Each place may want different templates, or different Javascript, or different CSS.
It doesn't make logical sense to put frontend stuff into the backend.

Agree, but can/should their be some "middle-end" which can exist between the two?  For much, the usage will be the same for each given task.  For instance, when adding, deleting, or configuring one of these industrial controllers, or when viewing a trend of some environmental parameter, the same group of parameters must be provided, the user experience is the same, and there is no reason the layout needs to differ.  As such, the HTML and JavaScript is the same as well as most if not all of the CSS.  I understand that there still needs to be a data only backend to both separate concerns as well as allow a totally different UX, however, to reduce deployment time as well as eliminating the need to maintain similar codes bases, would be have something in the middle.

If going down this path makes no sense, I suppose I could instead create a single class/object which has methods to get the associated HTML/JS/CSS for a given task, inject it into C5, Drupal, some 100% custom site, etc,  and then configure endpoints in each of these individual web apps to call the appropriate method of this object.  Or while IFRAMES are sometimes frowned on, maybe an option.