How do you test a proxy generated from OpanApi spec without having a target service

[dknezic · Accepted solution]

Have you considered mocking the target service?

[nabilhijazi]

To be honest, I did think of it. But I don't know how to do it :-(, short of developing full stub controllers for the API, which seems to defeat the purpose of having the generated proxy being the implementation of the controllers. This is actually puzzling me because it seems we have to do the controllers twice - once in the target service and once through the proxies.

[nabilhijazi]

I found out that Apigee has a mock target see https://docs.apigee.com/api-platform/samples/mock-target-api. I used that but I get errors from the proxy. I need to ask another question about those.

Thanks very much for your answer, it opened up the whole topic of Mock Servers for me. Uncle Google has a ton of references on Mock servers.

[nabilhijazi]

I wrote my own mock server in Spring Boot that does not parse the URI and just echoes the request. It works fine with the proxy generated from the spec. The proxy generated from the spec does not validate the spec - which was something I assumed it does.

[dchiesa1]

The proxy generated from the spec does not validate the spec

Correct. We're working on releasing a policy that would validate the inbound request against an OpenAPI Spec.

[nabilhijazi]

It seems like Apigee does nothing with the OpenApi specs. It does not help you develop your Api. You have to use some other way of developing your API from the specs. SwaggerHub is one way. It generates a mock server for you from the Specs, and it can fit in the development life cycle. I don't see Apigee helping with the development at all. Others have told me before, Apigee is not for developing the API, it is for managing it. But the docs, and marketing literature certainly don't say that. It took me quite a bit of pain (doing experiments on Apigee Edge is down right torture), to discover that giveing Apigee your specs is totally worthless for your development. Develop your proxies for managing your API, and develop the specs and the API using some other tool that allows mocking the API while it is in development.

[dchiesa1]

I'm sorry to hear that your experience did not meet your expectations. You're absolutely correct - Apigee does not provide tools to help develop an API. You can author a spec inside apigee Edge, though there are other tools that do that, and perhaps more ably.

Apigee does not have a "generate mock from spec" tool or feature. There are purpose-built point solutions for that, which Apigee can use.

Apigee does have a "generate API Proxy from spec", but that's just the proxy, the thing that sits in front of the API service (whether mock or not).

[nabilhijazi]

Thanks very much, Dino. I apologize for the harsh tone. I greatly enjoy your video tutorials and value your great expertise. I expected Apigee Edge to generate a mock from the spec, because the proxy, in a way is a mock of the Spec. You've done 90% of the work. What I still don't see is what value does generating the proxy from the spec add to the proxy? May as well leave the API parsing to the target server entirely, and create the proxy without the spec.

[DineshPalanivel]

@Dino-at-Google Thanks for the acknowledgement. I would like to hear how apigee will enhance the development/SDLC experience by factoring in the Open API spec as a key aspect.

Currently the experience is totally disconnected where, even if we start the proxy creation with open API spec, once the proxy is created and deployed, there is a total disconnect b/w Open API spec and the proxy. In this case, there is a tendency for developers to ignore the updates to Open API spec and it becomes stale.

On a side, to answer this question, we have two different target endpoints in our proxy which will route to the "real" backend and "mock" backend based on a header value.

The mock backend is actively maintained by the engineering teams using Wiremock. The same mock is used for running integration test cases (cucumber, apickli). This helps keep our CI environment independent of the backends and at the same time achieve CI reliability.

[nabilhijazi]

In a microservices architecture contex, the OpenApi spec is relevant only to the outside developer, to the Api Product. In the implementation architecture, chances are one public-facing API will generate 100 proxies. A proxy per path. So then the argument of generating one giant mock becomes moot. Also, only the public-facing endpoints need to be exposed to external developers. Most microservices will live in an event-driven world. One microservice endpoint, mapped to one path, is publicly exposed. Microservices "called" from that microservice are listening for an event, and their endpoint need not be exposed, they are visible only to the eventing infrastructure.