Giters

darklynx / request-baskets

HTTP requests collector to test webhooks, notifications, REST clients and more ...

Home Page:https://rbaskets.in

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Custom responses based on path or other matching criteria

nextrevision opened this issue · comments

commented

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

commented

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.:

  • .../mybasket/index.html
  • .../mybasket/description.html
  • .../mybasket/team.html
  • .../mybasket/articles.html
  • .../mybasket/about.html

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

commented

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:

  • GET /v1/products
  • GET /v1/products/{uuid}
  • GET /v1/orders

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

commented

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.