Hi Frank,
/tiers/{tier-level} is a collection. Using "api", "application" or
"resource" for {tier-level} parameter, we can retrieve the collections of
API, application or resource level tiers. We decided to use
/tiers/{tier-level} because in APIM itself they are maintained separately.
I.e. we
Hi Malintha,
sorry for the late response. A post is used on a collection to add a new
resource to this collection. While /tiers is for sure a collection, the
question is whether /tiers/{tier-level} is a collection too. Even if it
is, it sounds a bit strange to me to add a tier to a collection
Hi Malintha
The POST should go to /tiers/{tier-level} since if you are posting /tiers
you need to add an additional parameter. BTW is the tier model same for all
the levels ?
Thanks
Jo
On Tue, Dec 1, 2015 at 5:40 PM, Malintha Amarasinghe
wrote:
> Hi Nuwan,
>
> Thanks for
Hi Joe, Hi Nuwan,
Yes as of now we are using the same model for all levels. Bdw we have
following two attributes in the model which is specific to API tiers.
"stopOnQuotaReach": true,
"tierPlan": "FREE"
Would that be OK for having it for all levels? As we might be implementing
this in the
Hi Nuwan, Sanjeewa and Joe,
Thanks a lot for all the suggestions.
I have a small doubt for using the group as part of the path.
Lets say we use GET /tiers/api/{tier-id} to get a single API tier by its id
(actually Name). Then, are we exposing the resource /tiers alone too? If
we do, are we
Hi,
Another option is using a combined id. Ex: /tiers/{group}-{tiername}. That
is similar for the {provider}-{api}-{version} parameter we used for
identifying an API.
Thanks.
On Tue, Dec 1, 2015 at 3:17 PM, Malintha Amarasinghe
wrote:
> Hi Nuwan, Sanjeewa and Joe,
>
>
I think the group param should be mandatory. Therefore there will not be a
GET /tiers, but instead a GET /tiers/{level} only.
Thanks,
NuwanD.
On Tue, Dec 1, 2015 at 3:17 PM, Malintha Amarasinghe
wrote:
> Hi Nuwan, Sanjeewa and Joe,
>
> Thanks a lot for all the suggestions.
Hi Nuwan,
Thanks for the clarification.
Hi Frank,
Yes, would that need to be changed for POST /tiers/{tier-level}? Or shall
we keep the previous one (/tiers ) only for POST and identify the tier
level from the request body?
Thanks.
On Tue, Dec 1, 2015 at 5:32 PM, Frank Leymann
Just to double-check: but we still have a POST /tiers to add a new tier to
the collection, right?
Best regards,
Frank
2015-12-01 11:50 GMT+01:00 Nuwan Dias :
> I think the group param should be mandatory. Therefore there will not be a
> GET /tiers, but instead a GET
Hi All,
With the new REST API for API Manager we are exposing a resource /tiers for
retrieving/adding/updating tiers. Additionally we have a sub resource
/tiers/{tier-id}.
As of now, we have been using tier name as the tier-id. It did not give
problems as it could be used to identify a tier
@Sanjeewa, users migrating from older versions of API Manager will have
their tiers duplicated across all levels. And its not wrong for users to
have the same tier across all levels as well. Therefore having duplicate
tier names in different levels is valid scenario.
@Jo, yes there's a tier.xml
On Mon, Nov 30, 2015 at 11:05 PM, Malintha Amarasinghe
wrote:
> Hi All,
>
> With the new REST API for API Manager we are exposing a resource /tiers
> for retrieving/adding/updating tiers. Additionally we have a sub resource
> /tiers/{tier-id}.
>
> As of now, we have been
Hi Malintha
Do we have multiple tier.xml files per group ?
On Tue, Dec 1, 2015 at 7:41 AM, Sanjeewa Malalgoda
wrote:
>
>
> On Mon, Nov 30, 2015 at 11:05 PM, Malintha Amarasinghe > wrote:
>
>> Hi All,
>>
>> With the new REST API for API Manager we are
13 matches
Mail list logo