I do not like to say that developers can "create an API" in Apigee. Most developers, when they talk about "creating an API", are referring to the process of writing code, for example in Python, C#, or NodeJS/JavaScript, that handles GET/POST/PUT/DELETE on various paths. What you might describe in an OpenAPI Specification. You would then need to host that API implementation somewhere - in a VM, or in a container runner like "Cloud Run", or somewhere else.
There's a companion to that API implementation, an API client, which invokes that API, by sending in requests to the implementation. The client runs remotely. A single API implementation might have lots of different clients connecting to it, and even different varieties of clients.
In general, at runtime, Apigee acts as an API gateway. Rather than an API client connecting directly to your API implementation, the client would connect to Apigee, which looks like your API. Which is why we say, Apigee acts as a "proxy" for the real API. A "stand in". a facade.
Why would anyone do this? Why introduce another hop? Why have the client go through the proxy to get to the implementation? The reason is to get better management of the API. Sure, you can introduce API Authentication into your Python API. It might check for and validate OAuth tokens. But what if later you introduce another API, again written in Python? Are you going to cut/paste the API Authentication logic across both API implementations? What if you later introduce another API implemented in C#? And then one in Java, and one in JavaScript. Will you re-implement the API authentication for all of them? What if you want to implement a quota across these APIs? Or perform some sort of security analysis? What if you have an off-the-shelf API that is part of an existing packaged or SaaS app? This kind of thing cannot be easily extended.
A gateway allows you to separate those concerns out to a dedicated system - in this case Apigee. Your developers can still "create an API" in Python, but they don't need to implement OAuth token checking, or quotas / rate limiting, or security analysis. All of that is handled at the gateway, BEFORE the actual API implementation receives the request. If you have a single API, and a small number of clients , you probably don't need Apigee. You don't need to separate concerns out. But as you scale up, you will want more powerful tools for managing access to your heterogeneous set of APIs, and Apigee can help with that.
Getting back to your question, to use websocket in Apigee, you need to
- create your websocket server, and host it somewhere
- create your websocket client (or you can use a tool like Postman to invoke the Websocket server, just for testing and development)
- introduce Apigee as a proxy between them
To illustrate those steps more concretely, Here is a walkthrough of using Apigee with websocket. https://www.youtube.com/watch?v=TrGftwcI-Ps
Find the source code for this example here: https://github.com/DinoChiesa/Apigee-Websocket-Example
LinkedIn
Twitter
