Vladimir Dyuzhev
MockMotor Creator
Environment and Service Prefix URIs are Gone
A port per service works better with simple API GW products that do not transform the relative URIs.
NB: After the upgrade to 1.8.2565+, your services' URLs change!
What's Wrong with Prefix URIs?
For a long time, MockMotor routed the request to an appropriate mock environment and into an appropriate mock service by looking at the request URL.
If the request URL is /R90/account and there is an environment with /R90 prefix, the request is routed to that environment.
Similarly, if there is a service in that environment that has a /account prefix, the request is routed to that service.
That works perfectly with sophisticated web services products such as various ESBs. In their test environments, you configure the URL with the right prefixes, and the ESB calls the mocks now.
API GWs do not Play Along
However, some networking products are not aimed at flexibility but performance.
The most common class is the so-called API Gateways (APIGW). These products do not perform any URL translation, but route, after security checks, the external requests to internal web services. They can only change the hostname and port, and not URL.
Or, at best, changing the URL is a much more involved operation with them.
Using MockMotor with these products is not easy. For isolated services, it is possible to do a hack giving the mock environment a prefix matching the first segment of the URL. That, however, falls flat quickly when we need to map multiple services to the same mock environment, and they all have different first segments.
In fact, I'm aware of two commercial APIGW products that simply couldn't be used with MockMotor's URL prefixes.
But ESBs Support Port Mapping OK
The opposite is not true - the flexible ESB products that support URL mapping can also do port mapping as APIGWs do.
I.e. an ESB has no issues redirecting traffic to https://mockmotor/R90/accounts or https://mockmotor:21189/accounts.
That makes the port mapping a common denominator, supported by all products out there.
Service Ports
For reasons stated above, from release 1.8.2565, each mock service gets its own HTTP/HTTPS ports pair.
The services are available under MockMotor hostname, but under their own ports:
The lightbulb next to the port means that the port is open and accepts the connections.
Configuring the Ports
You can control the ports on the mock service configuration page:
The ports can be changed in the service configuration. The old ports (if any) are closed automatically, and the new ones are open immediately.
It is NOT required to restart MockMotor when changing the port
You can remove any of the ports from the service configuration. The service will not listen on that channel:
If there is an error opening a new port, MockMotor reports it:
New Services
New services, cloned services, and services, created during WSDL, OpenAPI or Fiddler imports, get a random pair of ports.
While they are random, their numbering still has some rules.
- Ports are starting from 20000
- Plain HTTP ports are ending with an even number (same way as HTTP 80 is even)
- HTTPS ports are ending with an odd number (same way as HTTPS 443 is odd)
- HTTPS port is one after the plain HTTP port (e.g. HTTP 20040 and HTTPS 20041)
If required, you can change those ports immediately or later.
HTTPS
HTTPS ports are accepting calls over the TLS1.2 protocol with all cyphers supported by the Java platform.
Trust
HTTPS ports in mock services accept all certificates, including the self-signed.
Identity Certificate
HTTPS ports are using the main MockMotor installation's identity certificate, configurable in the MockMotor Settings.