Ironclad / rivet

The open-source visual AI programming environment and TypeScript library
https://rivet.ironcladapp.com
MIT License
2.56k stars 226 forks source link

[Feature]: add support for templates in in HTTP headers & body (and perhaps in general) #285

Open mindplay-dk opened 6 months ago

mindplay-dk commented 6 months ago

Feature Request

It should be pretty obvious what I was trying to do here:

image

I figured putting {{var_name}} in e.g. Headers or Body inputs would cause an input to show up, so I could connect it to context.

Of course, there's pretty natural workaround, just use a text node:

image

It's just slightly less convenient - it would be nice if you didn't need to manually template outside of the HTTP call block to achieve this.

In fact, wouldn't it be nice if this feature just worked consistently everywhere, with any text input? 🙂

Code of Conduct

codemile commented 6 months ago

When we're coding HTTP requests, it's generally best practice to separate the HTTP configuration from the HTTP request, because you often have Bearer tokens, basepath, etc. that are needed by all your HTTP requests. This would be true if you were hitting a RESTful API where you need to make multiple calls with JWT tokens.

So one possible idea here, is to split this Http Call Node into 2 nodes. The HTTP config node would have more features to do what you want, and then you connect the output of the config to the HTTP request node. This would allow you to reuse your config across multiple request nodes.

Sadly, this makes it a bit more confusing for new users looking for something simple. Maybe we could make the HTTP Call Node output a config and also accept a config input (that is optional). That way you could reuse the node with other HTTP nodes, and you only setup your Bearer tokens once.

mindplay-dk commented 6 months ago

Ah, so if I understand correctly, it's like this "by design" - to make sure your configuration is done separately, so for example multiple HTTP clients can use the same config? That makes sense.

I wouldn't suggest splitting into two nodes, that sounds more complicated - since configuration needs to be done separately, we end up with a separate node either way, except, as you pointed out, for really simple cases where someone is just entering the values directly. Seem reasonable.

But I had to go to the Discord to learn what the correct input data format is. I had it wrong in the second screenshot above - it does not accept text for the headers, it has to be a JSON object with header names for keys.

I guess I would suggest one or two smaller changes then:

  1. Better on-screen documentation: something in the UI (possibly just a link to relevant docs) explaining which format is required for headers.

  2. Make the HTTP Call component accept plain text for headers. I would have guessed correctly then.

My guess was based on the headers input in the HTTP Call component, which is plain text - it seemed reasonable to expect the input would also be plain text then.

Plain text would be my personal preference, as this is closer to "reality" - I mean, that's all HTTP headers are.