[ANNOUNCE] openAPI-RED - yet another swagger-client node

Share Your Nodes
1

Hello again,

having just announced kdbx-RED, here comes the next project fresh outr of our oven: openAPI-RED.

Why another kind of swagger-client node? Well the ones that existed just didn't work for us (seems newer APIs are not supported by them at the moment). So we made our own.

Try it and let us know what you think about it. Feedback is very welcome.

Take a look at it's GitLab-page for more details.

Take care!

Chris

1 Like
2

Nice

if you are going to publish these to npm can you please look at our packaging (naming) guidelines before you do so please.... https://nodered.org/docs/creating-nodes/packaging#Naming

Thanks

3

Actually I did. It says:

Alternatively, any name that doesn’t use node-red as a prefix can be used.

I think that node-red-contrib- is quite a long prefix and makes the package names harder to read. That's why we decided to work with the postfix -red instead.

Is this a real issue? I asked that question in another thread before but didn't get an answer yet.

Please let me know if it is. If yes, it would be great if the guide gets updated though.

Thx for the feedback!

4

In the scheme of things to worry about these days it's not top of the list.
(though I see there is already https://flows.nodered.org/node/@node-red-tools/node-red-contrib-openapi :frowning: from just a couple of months ago - shame there was no collaboration to reduce confusion ... - ah well)

5

I think most will not recognise it as a node-red node if it does not follow the usual convention. Certainly I would not recognise it as such and would assume it was a nodejs module not a node-red one.

6

it's indexed in the flows site so should be ok.

7

@dceejay That's definitely true. Yes! We try to do our best anyway. So if there is a good reason to change naming-schemes, we will consider that. And about the other node: We searched for existing solutions. Maybe we just overlooked it or started with our development just a few days before. Anyway, we will take a look at it now. Maybe we can join forces. :slight_smile:

@Colin That's a valid point. And we didn't think of it. Anyway, I think as it is listed in the flow lib it should be ok. That's where we all search for nodes, don't we?

8

Hmm - if I try a file served locally that loads fine in my browser - http://localhost:1880/test.json - it gets a 404 error.

image
image1874Ă—100 19.8 KB

http://localhost:1880/getNewOpenApiInfo?openApiUrl=http://localhost:1880/test.json

9

There is also the hierarchical aspect to the naming. A node-red-contrib node is firstly node-red, then it is contributed (rather than core maintained which would be node-red-node-) then the next bit indicates the functionality.
Also the alphabetic sorting issue. In package.json dependencies the nodes appear alphabetically so one can easily see all the contrib nodes. Also when looking in the node_modules it is useful to be able to sort and find the contrib nodes.
All in all it would be better to stick to the convention.

3 Likes
10

Hmm... that shouldn't happen. We will look into it. Thanks for reporting!

11

The prefix node-red-contrib is something that we all recognise (as node-RED users), and gives us confidence that the node is designed specifically for use with node-RED, and therefore has less chance of breaking things.
Using this naming protocol has worked well so far for our community, why change things....

1 Like
12

Valid points that I do understand. So we will definitley discuss that internally.

Anyway, I have to say that this actually IS the current convention as it is mentioned in the documentation.

Maybe this should be discussed and clarified separate from this thread. In the end we need a decision whether naming-schemes like ours are also ok or whether the documentation needs an update. Otherwhise this will surely come up again.

13

@dceejay We tested it and it works for us. :thinking: Could you provide us with a sample flow to reproduce it? Thanks!

14

Absolutely correct.

The only requirement is that if you use node-red at the start of your node's name, then please use node-red-contrib-. If you don't use node-red at the start of your node's name then we don't care.

That is how it has always been. It has never been a requirement for all nodes to start with node-red-contrib-.

You get that confidence from the fact it's listed on flows.nodered.org.

2 Likes
15

Not much of a flow... just your node..

[{"id":"74dfff27.2a7d3","type":"openApi-red","z":"31d016ef.89a4ba","name":"sapient","openApiUrl":"http://localhost:1880/test.json","api":"","operation":"","operationData":{},"parameters":{},"x":340,"y":600,"wires":[[]]}]

but my settings.js has

httpAdminRoot: '/red',

and

httpStatic: '/Users/conway/node-red/web/',

which is the dir I serve my static files from (in this case the test.json)

16

Thanks for clarification, @knolleary!

17

Thanks - that information might just be what we need for testing. We never changed these settings. Will do so now. :slight_smile:

18

hmm - I think it's because you are using RED.httpAdmin.get and I'm sharing that file statically so it's not the admin path.May need some @knolleary advice here - as to best practise... as files like this (if hosted locally) feel like they should be in a users static directory... but what if that is also using authentication ? (I suppose when you hit load it should just prompt for user and password)

19

@2WeltenChris

That is the Node-RED official position

But @colin makes very good points that helps us users :slight_smile:

I always try to keep to existing conventions unless absolutely necessary to deviate

xkcd: Standards :slight_smile:

20

Indeed - but the documentation is the official position. If the community would like to suggest a change, then by all means do raise a PR with an alternative wording that can be discussed.

1 Like