API Implementation
I must be missing something about the basics of Apigee Edge. It seems that it helps in creating an API facade that provides an implementation home for many management and security functions - the API Proxy. The proxy then calls the target API. But I don't have a target API(yet)!. I finished my design and produced the specification. What will help me implement the target API! All the examples I've seen, so far, have an existing target API implementation that the API proxy fronts. I have not seen an example that implements an API (not just the proxy). Can someone point me to an example that does not start with an existing target implementation?
SwaggerHub, for example, generates code for a skeleton API implementation in many languages. I happen to favor Spring. It generates pretty good Spring code for a URL parser. The API is essentially a DSL for a URL pattern language. The first thing we need to start implementing the API is a parser for that DSL. SwaggerHut generates the server stub from the Swagger specification. How is that done in Apigee? The remaining tasks are callouts to backend services that either exist or initially stubbed and incrementally added as they are completed.
What am I missing?
Apigee is for API "Management" not for API Implementation,
However if you do not have a backend api, Still You Could build your implementation with polices like Javascript, Java callout or nodejs. For example Java callout policy could be configured to connect to database and implement database crud transactions then passing back transaction result to apigee runtime context where proxy response could be built.
But that's not what Apigee states in their documentation and in their marketing material, white papers, and eBooks.
Direct quote: An API gateway manages the entire API lifecycle.
- The API Lifecycle
- Design
- Develop
- Secure
- Publish
- ...
Build and deliver modern applications faster
- Build a bridge between legacy systems and modern applications
- Easily deliver partner and third-party offerings to customers through APIs
- Create a unified customer experience for your brand
- How APIs fuel connected experiences that customers demand
- ...
And so on.
"Design, Develop, Build, and Deliver APIs" are constant themes in ALL of Apigee's marketing and documentation.
The critical point here is that Apigee does not claim to manage the APIs only. It claims it can manage the entire API lifecycle. Big difference.
I hate to conclude that their claims are deceptive. I still think I must be missing something.
Basically what @Shawky Foda said..
We have recently been looking for something similar, but the automatic implementation of API "services", is not something Apigee gives you directly.
If speed of data delivery and disparate data sources are the problem you're trying to solve, you might want to look at iPaaS solutions, i.e. what is called "Data Integration", like Mulesoft Anypoint, Apache Nifi, Informatica, Denodo... all of which give you ways of connecting to your various backend data sources (databases, queues, flat files etc) and allow you to design data flows between them, from ingress, over transforms, all the ways into endpoints / APIs.
That stuff is amazing, but is of course much higher impact and a different focus than pure API Management.
That said, "DreamFactory" is something of a hybrid solution between the two, so perhaps you'll like that one.
Thank you for your recommendations. Re what @Shawky Foda said, please see my reply to him.
I evaluated both DreamFactory and SwaggerHub. I tested DreamFactory (awesome product) to migrate SOAP services. Also, I am not looking to connect to various data sources - but good suggestions, I'll need to research them). I don't know what my next API needs to do. Totally up to customer requirements. It really does not matter what my API does, I don't want to have two tools that parse the API, and then I need to integrate them. Bad practice for governance, too. You don't have a true trace for your API inventory. I have been seeing integrations between SwaggerHub and Apigee. But why doesn't Apigee just implement that integration themselves, in a way that is transparent to the API developer? It does not have to be SwaggerHub - SwaggerHub's approach to code generation from specifications - server stubs and client stubs), and make Apigee truely an API Lifecycle manager, not just an API Manager. They are already claiming that they are a lifecycle manager. But they need to add - an asterisk and, in smaller font, state: "you need another tool to develop your API - we just do proxies here".
How do we distinguish "api management" from "api development"? Where is the dividing line? Where does "development" end and "management" begins?
API design, API specification, API implementation (service implementation), API testing, API deployment, API maintenance, API versioning, API governance - all of these are "development", therefor Apigee is not concerned with them?
Are you saying that Apigee is not used in any of these "development" activities?
Apigee is involved only when we want to productize the API and publish it to app developers?
I am surprised there is not much interest in this issue. It is foundational.
Here is what I see is the simple fundamental truth about the Apigee API lifecycle:
1. It is definitely not API-First. It is code-first
2. Apigee's fundamental API life cycle ASSUMES that you have already developed your API and are offering its "backend services". When developing an Apigee proxy, you refer to the already published API as "the Target". But the origin of this mysterious "target" is never questioned - it is just an assumed fact. Everyone has their API already implemented when they start to design their API. Hey, wait a minute. That's the very definition of Catch-22.
When I start my API effort, I DO NOT HAVE an implementation of my API to make it the "Target".
As Foda points out, and I am inclined to agree with him, Apigee is not used by anyone STARTING to develop APIs.
For development of new APIs, the Apigee customer is faced with two options:
- Use the code-first approach to API development. Develop your API code-first using, say Spring. Spring can produce a Swagger specification from your code. When you are "done" with development, and have your back-end service up and running, then you can start using Apigee.
- Implement your API as a set of Apigee policies. You don't have the freedom to code your "API interpreter" - your controllers in Spring-speak. You can do only what Apigee decided you can do. If there is no policy for it, then you are faced with policy customization or feature requests.
I feel Apigee experts, perhaps Apigee itself, should address this question, as It has a profound effect on the development philosophy and methodology, not only management. And if true, then using Apigee would result in massive duplication. Essentially supporting two API lifecycles. One for development and one for management. I still feel that I must be missing something.
Best Answer
Let's try to shift your mindset a little bit on this topic.
1. Apigee API Lifecycle - "it is definitely not API-First. It is code-first."
API-First is typically a recommended perspective for the business, not technology. The concept states that as an organization that uses, produces, builds technologies to support their business, they will begin focusing on delivering APIs - first, as opposed to building other technologies first. For example, several enterprises have mobile applications, as well as websites. Those businesses will go off and produce the mobile apps, or web experiences, and in the process of building them, realize they need APIs, and then will either find, integrate or build the APIs they need for those channels. API-First states that you would build the APIs first, and then the channels, like mobile apps, or websites, or other internal tools, will consume the APIs that have already been built.. The starting point of this life-cycle is actually API DESIGN. The team is designing APIs (first) that will meet the needs of consumers, way before you code or build those APIs.
2. Apigee's fundamental API life cycle ....
First let's start with what is the API life cycle, and what you should be doing as part of that life cycle. If I was to simplify it, like any other development life cycle, I would have these basic phases.
Gather Requirements -> Design -> Develop -> Test -> Deploy -> Monetize -> Analyze
And then in my view, repeat, as part of your ongoing innovation and iteration initiatives.
Apigee doesn't assume anything. The Apigee platform is designed to help you manage APIs. That management includes developing, testing, deploying, publishing, monetizing and analyzing.
Apigee has tons of customers that started off with ZERO APIs.
They started off designing them, from an outside-in perspective, focused on user consumption, then using OpenAPI Initiative (OAI) to further describe and build an API Proxy.
They then worked on coding, using various policies, JS, etc to define the overall flow. You don't need a target. Now to your point, if you don't have a target, and depending on what you want your API to actually do, YES, you may need to setup a backend service to support your API. But that would be determined and decided as part of your DESIGN phase in the life cycle.
The policies inside of Apigee allow you to do a ton of things, to support multiple backend services, targets, applications, and again, yes, if there is not a policy that will do what you want it to do, you have the ability to develop your own policies.
All of this again, in an effort to help you manage your APIs. A gateway that has the capabilities to design, code, test, deploy, monetize, and analyze.
In summary -
API-First starts from a business perspective. A mandate from leadership to design and develop APIs as an essential element to drive business success. We typically don't see API-First as part of the lifecycle, it's part of the organizational culture.
API Life cycle starts with gathering requirements, including targets, services, and policies needed for your API, then they are designed. Once the API is designed from an outside-in perspective, then you can code it.
API Management with Apigee, is intended to help you manage your life cycle, and be able to support your APIs with Analytics and other tools directly inside of the platform, to continuously ensure that you are meeting the demands of your customers and your business.
Thank you, Chris. This is a very thorough response. I thought I was missing something. I am definitely missing many things! I need to understand the degrees of freedom that policies afford you. Do you lose any expressive power by abandoning your complete control over the API controller code? If your API is completely implemented, starting from the API specs in Swagger, it would seem that re-starting with Swagger to develop a facade that fronts the existing facade (that's what an API implementation is - a facade on a target service) is a duplication, and the existing facade needs to be removed - which means re-factoring your API implementation to remove duplication introduced by the Apigee approach. I still have a lot of questions, and several things in the Apigee API lifecycle still bother me. But I cannot fault Apigee for my ignorance. I am at the "I don't know what I don't know stage", and I do know a lot about API design and implementation. So the real response to my question is: go learn some more.
Thanks very much again.
How do I accept your answer? Do you have to convert your reply to an answer first?
I converted my reply to an answer. And you're right, it's hard when you don't know what we don't know. But that's why the forums and community are here, to help answer questions, and present new questions as we learn more. Keep reading up on these topics, and post whatever you need here, or search for your questions and see what others have already suggested. Happy to help!
