If you create a new request and try sending it immediately, there's an exception thrown.

Another nice-to-have would be to automatically convert between body types. If I've set a key-value-pair list as a multipart form body, and I switch to JSON, it would be lovely to see the key-value-pars automatically populated in a JSON object.

A webhook should be seen as a hosted endpoint for sending requests to.

The Webhook section of the app should allow you to create a named endpoint that will show all status of incoming requests. This functionality will be similar to https://webhook.site

It will provide a subdomain to send requests to, such as "https://enormously-stuck-tophat.api.horse"

The new/fork buttons don't really make sense the way I've implemented things. Instead, I think it would be super useful to put the requests into collections.

This beautiful screenshot shows the simple idea of a dropdown where you can name the current collection, or expand to get a "New collection" button.

The name of the collection is just for the viewer's benefit. It will still be stored as a ULID (as it currently is).

Secrets should be stored in the secrets tab along with the ability to automatically expand variables within requests.

If I choose a body type of "Json", and I haven't already set the Content-type header, there should be a button/link available to "Set header: Content-type: application/json". That would be a nice touch.

• Turbo updates the inner HTML of an element after the form automatically submits.
• The submit is done when an element loses focus.
• An element may lose focus when the user clicks another element.
• If the clicked element is within the replaced HTML, the click is lost, requiring a second click to register.

To simplify the UX for shared URLs, the collection switcher should be hidden when viewing a shared collection. The Fork button should be visible, along with the collection name, but there should be a link <- back to your collections to exit from the shared state.

Changing the name field, then pressing ENTER causes two Turbo events to fire.

This causes a race condition, where sometimes the page has to refresh because the old name isn't found (due to it already having been changed).

There's already a delete button on the request to remove it completely. I would like to see a clear button above the responses, to remove any record of old responses.

Depending on the Content-type header, display the body as formatted JSON, XML, YML, etc.

Now the app is taking shape, I want to see 100% unit test coverage.

The responses are currently shown in reverse-chronological order, but once #3 is implemented it will make more sense to display the responses in order, with the newest at the bottom of the list, but automatically open.

Inject variables in the same way as with secrets {{like_this}}, but this feature is to allow calculating variables by executing a script of some sort.

The main use case here is how Spektrix calculates its authentication header. It requires a multi-step cryptography process to generate a time-based auth header for each request. This is impossible to calculate prior to execution, so has to be generated on the fly for each request. I would love to use horsey to test this API!

If the user tries to edit something, an error box should appear to explain how the shared state is not editable, but you can fork it to make changes in your own collection.

The current implementation shows a list of responses associated to the current request, which only really makes sense if none of the parameters change on the request between responses.

If I create a request, execute it so I can see the response, and then change something like the query strings or method, what should happen to the existing responses? They could be deleted, but I think it would be better to keep them, but show what's changed.

This can be done using bindListCallback() here instead of bindList(). The ResponseEntity will need to take a reference of the RequestEntity in the constructor (like it used to), and then for each iteration it can check what's difference, and list out the changes to the page.

We've got "request", and we've got "web hook". A really cool feature would be "gateway".

Some APIs, like Stripe, have fantastic developer tooling. Every request I send to Stripe's API gets logged, and I can inspect the data coming in and going out, and I can share a request ID with their support team really easily.

Not all APIs are as good as Stripe's, but with an API Gateway, it could be.

Instead of sending your application's requests to the vendor's endpoint, send it to horsey's gateway instead, which will relay it on. Then you can inspect the request and response, logged like Stripe does, but for crappy APIs that don't offer logging!

An additional feature could be to handle weird/complex authentication, so your application can use a simple key when authenticating to horse.

When creating multiple requests in a collection, it would be nice to be able to re-order the requests.

Behat tests are great for testing this app's QA

The sponsorship page should take its content from the README.

On areas of the app that aren't finished, a popup should be displayed to explain that this is an always-free side project, built solely for my own benefit and to attract sponsorship.

It would be nice to see a settings page on the request tab to allow configuring the HTTP client.

• Timeout seconds
• User agent
• Follow redirects

Simple issue, probably to do with "click" vs "touch" events. There's actually an event type that covers both... I just can't remember it at the moment.

Currently we only have the CollectionRepository used throughout.

I want to remove all manipulation functions from this repository, such as save, create, etc. so that by default it's impossible to change the contents of a Collection.

Then, the ServiceLoader can check the ShareID in the URL matches the ShareID in the session, and if it does, return a PrivateCollectionRepository with the save, create methods implemented.

Then in the go function, we can disable all HTML fields if !$collectionRepository instanceof SharedCollectionRepository, but we don't need to worry about client side security, because the methods are simply not there unless the session is set correctly.

Only use a fun ID if the name isn't supplied, otherwise create a slug from the name.

This would make more professional URLs for sharing. Example: https://api.horse/request/01HT0FZCA9E17TSNN50R/github-api/list-all-repos/ rather than it ending with supremely-gregarious-ostrich or whatever.

The fun IDs are easter eggs but shouldn't be forced on all URLs.