You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
Activity
tarttelin commentedon Nov 9, 2016
Interesting. I wonder if stubby4j might be a better fit for this use-case?
rickb777 commentedon Nov 9, 2016
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.