常用的几个开源 API网关管理系统
来源:互联网 发布:施工横道图绘制软件 编辑:程序博客网 时间:2024/06/05 16:32
The primary purpose of a web API is to expose data to be consumed or changed. Fairly quickly, the question of securing access to such data presents itself. And other aspects become critical too, such as performance management API or the respect of access quotas.
When it comes to a single API, the most direct approach to treat these secondary but important needs is to directly add these responsibilities in the API itself. Many solutions exist for this. Security solutions can be more or less sophisticated: simple htaccess protecting access to resources, using a library such as spring Security or Apache Shiro if developments are made in Java, Passport with NodeJS bookstore, etc. Once the caller’s identity is known, quota management is only a matter of reads & writes to a counter. Cache management can be done through dedicated libraries or by the same libraries used to build the API (Jersey, Restlet, etc.)
Since creating a Web API is now rather simple, APIs tend to proliferate. When the number of APIs becomes quite important, these requirements obviously can be considered cross-cutting needs. And therefore it is not unreasonable to suggest that they can be treated outside the API.
How to implement these cross-cutting needs? A reverse proxy is a possible approach. This component is commonly called an API Gateway.
A typical API Gateway includes:
- Security (authentication, and potentially, authorization)
- Managing access quotas and throttling
- Caching (proxy statements and cache)
- API Composition and Processing
- Routing (possibly processing) to an “internal” API
- API health monitoring (performance monitoring, error …)
- Versioning (with the possible negotiation of automatic version)
Advantages:
- Implemented in one single place
- Simplifies the API source code itself, since these concerns are externalized
- Provides a central and unique view of the API and therefore be more likely to allow a consistent policy
Drawbacks:
- Possible single point of failure or bottleneck
- Risk of complexity, since all the API rules are in one place
- Risk of lock-in, and migrating away may not be simple
Is it a great idea that nobody has thought of yet? No, far from it, since many publishers now have solutions of this kind, with variable amounts of features and different maturity levels. Commercial products are now numerous and started to get acquired by large publishers cycles (example: Intel acquired Mashery in 2013, Computer Associates acquired Layer 7 in 2013) or to enter partnerships (SAP and Apigee 2014). Not all are equal, some stand out and have already gained notoriety (Layer 7 for instance, with his API guru workforce).
What about open-source?
There are some open source initiatives but strangely, this market is yet to be taken (anyone up for it?):
- APIAxle ( http://apiaxle.com/ )
- Tyk ( http://tyk.io/ )
- apiGrove ( http://apigrove.net/ )
- WSO2 API Manager ( http://wso2.com/products/api-manager/ )
All these solutions do not have the same traction in the world of open source and are not equal, far from it, in terms of features. To date, WSO2 API Manager is the richest in features and is well-polished. It is a good platform candidate to implement an API Gateway at a reasonable cost (cost of learning the technology and deploying it). Even though this solution is advanced, it does not necessarily cover the full spectrum of features of its commercial competitors.
There is always the possibility of custom-assembling a solution when the needs do not seem to justify the adoption of a turnkey product. Several open source reverse proxy solutions can be configured to provide the basic functionality of an API Gateway. But beware the long-term costs of this approach.
In conclusion, carefully analyze your needs to identify the appropriate strategy: supporting these aspects in the API itself may look like a good and cheap option, but it will lose its appeal if your API portfolio grows. Soon enough, the adoption of a specialized solution will prove to be a good investment. Whether it is open source or not, free or not, custom or off the shelf, on-premise or SaaS, and so on, will depend on many other parameters that need to be examined.
来源: http://www.ipponusa.com/blog/api-gateway/
- 常用的几个开源 API网关管理系统
- 常用的几个开源 API网关管理系统
- 几个常用的Win32 Api
- 几个不常用的API
- 常用的几个网络api
- 几个开源的运维管理系统介绍
- 几个常用的API HOOK的工具包
- JAVA API下几个常用的包
- JAVA API下几个常用的包
- 整理几个常用的字符串API
- 免费开源的api接口管理系统,移动时代首选接口管理平台-doclever
- Linux服务器常用的几个管理命令
- 几个管理系统的框架(一)
- 学生管理系统的几个设计模式
- 基于nginx的api网关
- 企业级API网关的设计
- 企业级API网关的设计
- 进程管理的常用api的分类
- bower入门
- 做外贸要收款,哪些是没有拒付、效果比较好的?
- 网络爬虫--数据处理,jsoup工具解析html,dom4j解析xml
- 你值得拥有:25个Linux性能监控工具
- 原生二维码扫描实现, 二维码、中间带小图标、条形码生成
- 常用的几个开源 API网关管理系统
- Java中字符串indexof() 的使用方法
- Vue.js的组件(六)分发 之 具名Slot
- IOS真机上使用XMPP 调试时遇到的问题
- go的并发机制goroutine
- 麦克风阵列处理之TF-GSC 广义旁瓣相消器
- Java提高篇(三四)-----fail-fast机制
- 使用git时遇到的坑 non-fast-forward
- StreamVR插件详解二:UI及手柄