Feature Request: Proxy another API

[bitwit]

Originally requested on Twitter last week but formalizing into Github:

We have an existing API Service that we want to stub with new/changed endpoints at the beginning of a sprint. Ideally, when an endpoint isn't mocked, it goes straight to the original source but responds with the mock when something is in mockbin.

[ahmadnassri]

First, there are a couple of things in the works that are a dependencies to achieve this:

• [ ] Hostname specific rules #9
• [ ] named bin endpoints #13

so, I have a few poll questions here:

• Would you rather use traditional Proxy methods (headers) to successfully proxy a request
  • an example of this would be simply setting the "proxy" endpoint (mockbin) in your http library of choice and let it handle the rest
• would proxying ALL requests to the same bin be more convenient, or assuming a single bin per endpoint structure?

example 1:

myapi.com/my/endpoint --> mockbin.com/bin/xxx/my/endpoint
myapi.com/my/other/endpoint --> mockbin.com/bin/xxx/my/other/endpoint

example 2:

myapi.com/my/endpoint --> myapi.mockbin.com/my/endpoint
myapi.com/my/other/endpoint --> mockbin.com/my/other/endpoint

the pros/cons here are (if not obvious)

• example 1:
  • seeing all your request history to any endpoint in one place
  • no need to setup any additional bins
  • all bins will have the same response
• example 2:
  • your very own subdomain
  • no capture of none-mocked endpoints
  • each bin can have different response

[bitwit]

Hmm interesting questions

For our use case I believe we are looking for a traditional proxy method and setting something like 'mockbin.com/bin/xxx/' as the base url of all our http requests.

The feature of having a subdomain and different endpoints for every bin does seem useful, particularly if you've got lots of endpoints to mock, but more like a nice to have IMO. Typically we wouldn't be expecting to mock more than a handful of requests at a time.

[bitwit]

I've been playing around with the bins a little more, now that I understand what I was doing wrong in #18 and wanted to clarify one thing;

So if all my api was going through a bin, I would need a way to specify what specific path fragment uses the bin or not, yes? Alternatively, if I need more than one endpoint for my API mocked, I actually will need multiple bins?

In this case, your example 2 makes more sense to me now, ( I assume both endpoints in your example would be going through the myapi.mockbin subdomain though. Typo?)

[ahmadnassri]

I was thinking of using Proxy Authentication for this:

curl myapi.com/endpoint

with proxy mode:

curl myapi.com/endpoint --proxy mockbin.org:80 --proxy-auth bin:uuid

results are logged at mockbin.org/bin/uuid

where: "uuid", is the Bin ID.

or say, you are using HTTP library X:

x->request('GET', 'myapi.com/endpoint')

with proxy mode:

x->proxy('mockbin.org:80')
x->proxyAuth('bin:uuid')
x->request('GET', 'myapi.com/endpoint')

the challenge here is that not all HTTP libraries support proxying, and not all support Proxy Auth headers.

of course this is all doable manually, just set the appropriate headers with your code and you're done.

the idea here is for a quick way to add/remove mockbin into any existing codebase, without expecting the developer to update endpoints / base urls.

this is even more useful on a network level to debug what 3rd party SDKs are doing in your code.

simply set mock bin as your local network proxy and watch all your http requests logged

[bitwit]

Ahh yes, I see where you are coming from now.

We spun this up on docker and tested locally so the idea of rerouting all traffic through the mock service wasn't a big deal. That's probably not ideal for the Mashape hosted version though.

I had been thinking it exists as a setting on the bin, or bin 'group' somehow. Then we'd say that you can hit sprint.myapi.com immediately to see the agreed upon changes to 1 or more endpoints mocked while getting the rest of the service as usual.