TOML Support

[helloanoop]

Overview

This discussion aims to explore the possibility of using .toml as the preferred format for saving API request data instead of .bru. For the progression of the Domain-Specific Language (DSL), see #360

I've been seriously exploring how we can represent api requests in toml
After careful consideration, factoring in various edge cases, toml seems to fulfil our requirements and might offer better long-term benefits.

Why TOML

• Well established format
• Utilize syntax highlighting in IDEs
• Leverage existing tooling for toml file manipulation
• Git providers (like GitHub, Bitbucket) offer syntax highlighting while reviewing pull requests on the web

Tasks

• Experimental support for working with TOML in GUI
• Experimental support for working with TOML in CLI
• Gather Community feedback during our community call on Wed Jan 3rd 2024

More Tasks TBD based on how the experiment turns out

Looming Issues

Several features are currently blocked due to limitations in the bru language. Some include:

1. Describing headers
2. Managing choices for query parameters
3. File upload capabilities
4. Storing multiple payloads within a single request

To address these limitations, I see two potential paths:

1. Enhance Bru Lang
2. Utilize TOML

Next Steps

Before choosing a direction, I aim to implement experimental TOML support in our current app within the next 3-4 days (by January 1st, 2024). . BTW I am working on bruno Full Time from Jan 1st :)

Sample GET Request

[kishaningithub]

I feel that TOML should be the way forward. Would appreciate more articles on TOML vs bru as you move forward with the next steps.

[nateshmbhat]

any update on this ? this seems very interseting

[hp77-creator]

Hey @helloanoop, just wanted to know did you also explore/consider YAML for the language?

[hp77-creator]

Hey @helloanoop, just wanted to know did you also explore/consider YAML for the language?

My bad, went through #360 , indentation hell 🤔 interesting, I mean at one point it can become that but then at that point your API design is not good, It will be on the type of API imo.

[jzorn]

I think TOML is a better format for humans. It's too easy to mess things up in YAML.

[DenisMir]

Any progress on this? There are so much bugs just going back to the custom bru DSL. It would be awesome to get rid of all of them. (e.g. the colon bug)

[helloanoop]

We will move very soon (max 2 weeks) to support YAML to save the requests

@lohxt1 on our team is already working on it.
There is a lot of nuance on TOML support, I will add detailed notes later

TLDR; - YAML support to arrive soon, TOML will need more time

[aarjithn]

@helloanoop my 2c is to stick with just one. If its yaml so be it. Who are very particular can setup conversion to/from toml

Maybe depreciate and support bru for a while but going down path of multiple config languages would be a pain

[skhaz]

I do not think a custom language for settings a good idea.

Please try to stick to toml or yaml, do not reinvent the wheel.

[DenisMir]

Yeah. E.g. not allowing to have "colons" in your custom format for values is a bad joke. That is why inventing some custom configuration format is definitely a pain and just leads to bugs that normally would not be a problem with a basic standard format.