I’m working on designing a node that functions as an API client to a specific website. I’ve actually written several essays on how this website is as if they tried to put together a practical guide of worst practices for creating an API. Because of that it’s a horrible API to consume and I’m hoping to mitigate part of that in this node. A practical example is that one endpoint to get the user’s profile mixes booleans and “y”/“n” strings in the same JSON response, and in other places uses 0/1 to represent a boolean. On top of that, the API documentation does not match the actual data returned. This is the kind of website where the 404 error’s extended response is “something goofed, please try again”.
A very practical part of what has been horribly implemented is that the public and internal share the same authentication endpoints and due to lack of proper authorisation, users registered for the public API can use internal endpoints. I have informed the engineering team of the website of this several times, but it appears they’ve chosen to ignore it. Since they’ve responded to other correspondence of mine, I’m assuming that the ignoring is deliberate.
As such, I’m hoping to do the same concept here as I did when writing a Python API client last year, and use an extension model. For that library, I released a raw client and a core extension exposing the public API, with a wrapper on top that put those together and functioned as actual client you would install and use, depending on both components. I also wrote several extensions for the internal API that could be connected to the wrapper client/core using the same model. To the general public, only the public API is available but if you’ve access to the extensions you can use the internal API with the same tooling.
This is not the extension model I’ve in mind for this node however. My idea is to set up the public endpoints in the node and selectable from a dropdown on the configuration screen, but allow a user to add endpoints that aren’t exposed by default. My idea for this was to set up a config node where rules/endpoints can be defined, and (optionally) a parser for each of these custom endpoints with a JSONata query to generalise/improve/fix the response from the API. Each of those rules would define things like endpoint, http method, url parameters, body parameters, content type, and the like. Beyond that, I’m hoping to add import/export buttons so extra endpoint definitions can be shared without needing to export the configuration node itself and in an easily readable format.
I know that the user will have to deploy the config node upon changes before I could refer to them elsewhere. How would I best expand the dropdown in the base node’s configuration screen to include additional endpoints defined in the configuration node? I’m assuming I would need to add a custom http endpoint to the node itself that returns the list upon call, but can I access the configuration node’s id in the html to properly call this endpoint?
I’m definitely open for other suggestions and feedback as well.
