4 ms·

Did you consider adopting the OpenAPI standard for specifying the mock endpoints and their responses?

• ankit84 4y ago
  There is another hosted mock Beeceptor.com it has support for http mocking, intercepting, proxying, tunneling and single click OAS Mock setup.
• dhuan_ 4y ago
  No, I didn't think of that yet. But yes I can see the benefit. The thing is that Mock's endpoint configuration format enables you do custom things that afaik OpenAPI wasn't designed for. In Mock's endpoint configuration you can set routes to return different responses based on conditions - say if route such was requested with querystring values such and such, then such response would be returned, and so on. Imagine for example mocking MediaWiki's API where you have a single "api.php" endpoint, where you determine the "action" of the API operation with querystrings. Mock was used here to mock their API enabling me to easily do E2E tests: https://github.com/dhuan/wikicmd/blob/master/tests/e2e/mock/config/config.json https://github.com/dhuan/wikicmd/blob/master/tests/e2e/mock/...
  • a1445c8b 4y ago
    Ah, I understand now. As a potential user though, I think if the tool worked with the OpenAPI one way or another, I'd be able to mock a service's API much faster. For example, maybe it can ingest OpenAPI and transpile it to your tool's schema. Or maybe your tool's schema could be a superset of OpenAPI. Whichever implementation you choose, as long as it helps me avoid rewriting parts of the config that can easily be inferred from existing docs/schemas, that'd be a huge win.
    • dhuan_ 4y ago
      Makes sense. Thanks for the suggestion. Indeed it'd be convenient to have that one day.