search

darklynx / request-baskets

HTTP requests collector to test webhooks, notifications, REST clients and more ...
https://rbaskets.in
MIT License
347 stars 51 forks source link

Custom responses based on path or other matching criteria #26

Open nextrevision opened 6 years ago

nextrevision commented 6 years ago

Currently, custom responses can be set and matched by method. It would be cool to allow matching by other attributes like path and header.

darklynx commented 6 years ago

I had already such an idea in mind, especially after I have figured out that basket can be used to build a small web site, e.g.:

Rename mybasket to docs or html and you've got a classical web-site behind a request basket.

But in the end I decided that this deviates too much from the original idea of the Request Baskets service:

collect the incoming HTTP notifications / web hook requests on the public end-point and allow to fetch the collected data via secured REST API.

The service was intended as a helper to write unit/integration tests for the logic that communicates with external services, has to react on notifications from them, and run such tests on the developer machine or CI server that cannot set up a public listener to catch notifications due to firewall rules, located behind router (LAN), or any other technical or security restrictions.

However, I'm open to reconsider my original thoughts and implement/accept the reasonable dynamics in HTTP responses configuration.

ℹ️ btw, right now you can already template the responses and it take query parameters as input. Templates are expected in a strange Go HTML template format, which is quite reach by itself, though very unusual for newcomers.

Example of response template that would welcome any query parameter name:

<html>
<head>
  <title>Welcome page</title>
</head>
<body>
  <h3>Welcome</h3>
  <p>Hello {{range .name}}<b>{{.}}</b>, {{end}}
  <p>Welcome to Request Baskets world!
</body>
</html>

You can try it out: https://rbaskets.in/welcome?name=Bob&name=Anna

nextrevision commented 6 years ago

Ahh I see, that makes sense. I suppose that covers the use case for headers and parameters, which fit in well with the template. I definitely see using request-baskets for API testing/mocking and could see there being some use in different responses for different API paths, such as:

I suppose this could all be accomplished in a template, just wondering if it would be easier defining multiple responses based on paths and then using templates to fill in some data/perform basic conditionals for each of those responses when needed.

Curious to know what you think though

darklynx commented 6 years ago

Well, if use cases for Request Baskets are extended to use the service for REST API mocking, then of course, it make sense to provide more flexible ways to configure responses within a single basket.

In past I have evaluated several possibilities for REST API mocking and decided that there are already nice open source services for that purpose and Request Baskets should not compete on that field :)

Yet, I have nothing against of extending the API to provide more flexibility. The only wish from my side for such improvements is to keep API and UI simple and clear for users.