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.
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/pathmight set up a one-shot expectation akin to calling
StubServer.expect. Similarly,POST /admin/stub/GET/uri/pathmight 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/verifymight be akin to calling
StubServer.verify, albeit returning its outcome in JSON.