gravitee-io / issues

Gravitee.io - API Platform - Issues
65 stars 26 forks source link

Common Plan for APIs #726

Open shoaibjdev opened 7 years ago

shoaibjdev commented 7 years ago

It's really too much work which is redundant to create same plan for all APIs. There should be a way to define a Plan separately from the API and then choose those Plans for APIs wherever applicable.

An API gateway & management solutions are used in situation when you have large number of APIs (such as hundreds of APIs) and to create Plan for each API is repetitive work where you could make mistakes. Also if you need to just change a number (such as number of API calls per minute) in all those plans, it's likely to make mistakes.

@graviteeio Team - you guys have offered an amazing API platform and that too Open source. Kindly consider the above request.

brasseld commented 7 years ago

This is a duplicate of #378

An other option if you have plenty of APIs and plans would be to use / call the Management API from a script / job / ...

Thanks for you latest comment. If you want to talk / provide feedbacks on the gio platform, you are very welcome!

shoaibjdev commented 7 years ago

Hi @brasseld - I agree we can make use of management REST API calls through scripts but as you guys have really done a wonderful job offering a UI for Management and this is what makes GraviteeIO platform more advanced and rich compared to other Open Source API Management solutions. Other solutions out there like Kong is good but they lack management UI which make it's less intresting and people start looking for commercial offerings as they provide native UIs.

I request you to consider it as a feature request on your road map as I believe it would be later a difficult change to implement considering architectural impact. Also was thinking of if there is way from backend database to link the same Plan id to all apis by running a mongodb script or something. Haven't reviewed the code or data structure yet but if you can guide on how is it implemented on backend may be we could try just updating all API's Plan Id to same in database or adding a drop down on the UI to fetch all available Plans from existing API's and link it there itself.

gs11 commented 6 years ago

I think #378 is not really the same as it concerns reusable templates that will result in multiple plans.

What's mentioned here and that I'd wish for is the possibility to use the very same plan for multiple APIs. Thus it'd be possible to recreate/add APIs (for a plan) without affecting the API consumers too much by forcing them to update API keys etc.

brasseld commented 6 years ago

Hi @gs11

So, in that case, the plan would not be managed from a single API. Who (which kind of user) has the responsibility to create such multi-API plan ?

When you're subscribing to an API, are you also looking for subscribing to other APIs ? IMHO, this is just a matter of how API Key are managed. From the very beginning, API Keys were associated to a subscription for a single plan / API. As we have the concept of application, perhaps the API-Key should be managed at the application's level, and not the subscription / plan itself...

Also, I'm thinking about this solution because we do not meet the same "problem" when using OAuth2 or JWT plan.

WDYT ?

gs11 commented 6 years ago

Thanks @brasseld

I haven't used roles and permissions so far...just relied on administrator access but I can see the challenges you probably think of with users.

I presume that today (only) users with permissions MANAGEMENT / API can create/delete APIs? My thinking is that the same permissions should allow creating/assigning (sharable) plans to APIs but that would mean that users with only API / PLAN permissions would lose the administration possibilities.

Personally, I'd like to subscribe to the logical group of APIs, and it'd be up to the API publisher to define what that logical unit is...only a single API or a group of them (micro services).

Isn't the subscription/API key already managed on the application level?