search

usebruno / bruno

Opensource IDE For Exploring and Testing Api's (lightweight alternative to postman/insomnia)
https://www.usebruno.com/
MIT License
28.05k stars 1.3k forks source link

Re-consider having seq as part of API definition #841

Open vboctor opened 1 year ago

vboctor commented 1 year ago

Where an API is positioned in a folder isn't really part of the API definition. It would be great if this can be removed from the bru file. Following are some reasons:

  1. Removing or adding an API to the top of a list now, will result on all APIs in the folder showing up as updated.
  2. Duplicating an API or copying and pasting will require manual revisiting of seq in the newly manually added API file + all other files in the same folder.

It would be great if there is there is a manifest file in the folder that captures folder level properties + ordering of the APIs. If an API file is manually added and is not in the manifest, then the client should add it to the end and update the manifest file.

This reduces the noise on git commits and makes the API files focus on the definition and not the view aspects like the ordering.

The manifest can be the equivalent of a collection definition file or a folder definition file.

the8tre commented 12 months ago

Totally agree with that. I'd rather have a unique id for each of the .bru file with their ordering maintained into the bruno.json collection file. Reordering would impact only the collection and not the individual requests.

timo-abele commented 12 months ago

For what it's worth, a quick fix to point "1." would be to relax the seq type to floating point numbers. Default assignment would continue in the same way: 1.0, 2.0, ... and as requests get moved around there is always free space for the new seq, e.g. 1.5 so no other requests have to be adjusted. There can still be clashes if a file is moved into an existing folder, but I don't think that this can be helped.

However, I too think that the order should not be part of the request, as I view the request itself and its presentation as separate concerns. For the implementation of unique id:s, I see the following options:

  1. Hash value of the file. Not practical, because we want to keep the id as the file content (and thus the hash value) changes.
  2. Assign id in the .bru file of the request, reference it in bruno.json or rather a manifest in the same folder. Not ideal. Introduces coupling between files, and user can introduce duplicate id:s by accident (e.g. moving requests between folders in the terminal)
  3. Use filename¹ as id. "organic" unique id, file system prevents duplicates, no redundancies

¹ Relative filepath when centrally managed in bruno.json per collection. I prefer to define the order per folder in an order file, which keeps things local.

lapo-luchini commented 6 months ago

I'd rather have a unique id for each of the .bru file with their ordering maintained into the bruno.json collection file.

I would love that too! Also, managing the sort order in the collection JSON file would allow to sort folders as well, which is currently impossible (and while alphabetical ordering is a very good default, sometimes I would prefer to manually sort by importance / frequency of use).