Specification interoperability

[gautaz]

Hello,

I am wondering if interoperability was one of the original goals of this specification.

I am in particular pointing the fact that ECMAScript was chosen as the scripting language.

This means that any editor/IDE supporting this specification also has to support ECMAScript, which seems a bit overkill.

AFAIK the reasoning behind this is to be able to reuse data between requests, a simple DSL fitted for this purpose would be far easier to integrate in any editor.

See rest-nvim/rest.nvim#205 for additional examples of where this choice leads to.

[zinoviy23]

I guess not. One of the main reasons was helping our community (users of HTTP Client in JetBrains IDEs) to implement their own out-of-IDE HTTP Requests runners before we introduced our own.

Currently, this repository is not well maintained because it is hard to maintain a specification and deliver new features. In addition, there is official documentation, which currently feels enough. So, it is a bit abandoned right now.

reasoning behind this is to be able to reuse data between requests, a simple DSL

No, it has a bit more, like creating and manipulating such data before passing to the (next) request. In addition, there is an API for writing tests. So, I guess in total, it wouldn't be a simple DSL and supporting it in different editors will be harder than supporting JS, which has support in most editors nowadays.

I can add that JS is used because it is appropriate for people from different development backgrounds, and covers more or less all people who want to send HTTP Requests.

But I think there will be discussions about .http format specifications for different editors because there are a bunch of different (you mentioned another one😁) implementations. You can check it here: dotnet/AspNetCore.Docs#29431

[gautaz]

Thanks @zinoviy23 for your insight.

I agree that a DSL would not be simple if manipulating data is needed.
Nevertheless, I am not quite sure that manipulating data is needed most of the time.

The DSL could start with a simple feature set and evolve over time.
The DSL specification can be versioned and editors can adapt at their own pace.

On the other hand, requiring ECMAScript seems quite excessive compared to the need.

supporting JS, which has support in most editors nowadays.

Not sure what do you include in most editors.
This will probably seem old school for junior developers but Emacs and vim/neovim do not include a JS engine for instance and they still seem widely used.

Will such a specification last if it relies on a language because it is used to develop some editors?
What will we do with all our .http files if the next generation editors are developed in go/rust/julia or whatever new language that gains traction?

Anyway, you are right, the discussions on this matter are just starting and I hope it will be for the best as usual 🙂.

[zinoviy23]

developers but Emacs and vim/neovim do not include a JS engine for instance and they still seem widely used.

In "has support" I meant that most of the editors have plugins for JS, including *vim and Emacs😁 And as I know, it is quite popular for JS developers to use Neovim with a bunch of plugins.

About new generation editors, I think that JS in the specification or the language of the editor is not important. Because, as I understand, a common way of supporting languages in lightweight editors is moving language processing logic out of the editor process (via some kind of language server, e.g. using Language Server Protocol).
So, I guess, new editors can just reuse big parts of existing plugins for the current generation of editors.

Moreover, I can imagine a hypothetical Neovim plugin for .http files by JetBrains that can be implemented right now🤯
It will have two parts: a plugin for the editor side and an executor (e.g. using our CLI runner). The editor part will have just lexical highlighting (for keywords in HTTP Language and JS for scripts), and a shortcut for executing requests. This shortcut will just call the CLI part and show the output inside the editor.
And such an approach should work for other editors, even newer ones.

[gautaz]

It still feels like hitting the tack with a sledgehammer, I guess we can only agree on our disagreement.
I close the issue as you already said it before, this specification is unmaintained so arguing here won't probably solve it.
It was nice having some feedback from the Jetbrains side 🙂, thanks for the input.

[wekempf]

@gautaz We'll have to agree to disagree. I've used several of these HTTP clients, and the ones that don't support JS simply don't work for me. All the "magic" required to support the simple things, like standard security mechanisms, are unintuitive at best. Worse, that's for the standard stuff, move out of that realm and your just out of luck. Then there's API chaining and testing to consider. Good luck designing a DSL for that which isn't as complicated as JS. Ideally editors would use a LSP implementation and there'd be good CLI runners, and embedding JS isn't that difficult to do. I don't see using JS as overkill, and in fact see it is the ideal solution.