Open rickb777 opened 8 years ago
Interesting. I wonder if stubby4j might be a better fit for this use-case?
I've been thinking about stubby4j, but it's a slightly different beast. JavaStubServer could behave 'in loco' as a stub of a microservice, albeit with an HTTP-programmable behaviour and, optionally, stubbing configured at startup by a wrapper 'main'. The intent would be a drop-in replacement for a real service as a self-hosting (Jetty) service.
Stubby4j is packaged differently.
Perhaps I ought to try out an outline of what I have in mind via another PR.
Perhaps it should be a separate repo that depends on JavaStubServer.
Idea for discussion:
We could add an endpoint that would accept GET/PUT/POST/DELETE requests 'restfully'. Under such control, the server would operate as a stubbed microservice. The purpose would be to operate as a tool during integration testing, replacing the need to stub 'normal' microservices on an ad-hoc basis.
Supposing that "/admin" is a configurable path,
POST /admin/expect/GET/uri/path
might set up a one-shot expectation akin to calling
StubServer.expect
. Similarly,POST /admin/stub/GET/uri/path
might set up a multi-use expectation akin to calling
StubServer.stub
. In each case, The request header expectations would perhaps be included in the request entity. GET, PUT and DELETE methods might be provided for inspection and alteration.GET /admin/verify
might be akin to calling
StubServer.verify
, albeit returning its outcome in JSON.