Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Custom responses based on path or other matching criteria #26

Open
nextrevision opened this issue May 3, 2018 · 3 comments
Open

Custom responses based on path or other matching criteria #26

nextrevision opened this issue May 3, 2018 · 3 comments
Labels
question

Comments

@nextrevision
Copy link
Contributor

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
Copy link
Owner

darklynx commented May 3, 2018

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

@darklynx darklynx mentioned this issue May 3, 2018
Closed
@nextrevision
Copy link
Contributor Author

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

@darklynx
Copy link
Owner

darklynx commented May 4, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
question
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@darklynx @nextrevision