Hi,
According to the discussion, there are concerns of making a published API
editable. As Chamin, Shani suggested we can get over this by clearly
defining what fields we make editable. But that itself is an additional
complexity we are introducing and we have to book-keep on new fields we
Hi,
I think we need to carefully identify the fields that we are going to make
editable, if we are going to support this. Think of an example where a
consumer is using a particular API (based on his roles). If we change the
eligible role list for that API (i.e - visible roles), then some of the
Hi,
I don't think we should allow the API to be edited once it is published. If
there is a bug in the API , then it should be fixed and released as a new
version IMO. I was referring to this [1]. And they say that "Publishing is
a way to show that the API is in a stable state and its endpoints
Hi All,
On Fri, Mar 31, 2017 at 7:00 AM Chamalee De Silva wrote:
> Hi,
> Agree with Raj and Nuwan.
>
> But considering the user PoV,
> In a situation where we change state of an Published API to maintenance
> state, make the change and published back,
> what if the subscriber
Hi,
Agree with Raj and Nuwan.
But considering the user PoV,
In a situation where we change state of an Published API to maintenance
state, make the change and published back,
what if the subscriber is not happy with the updates which makes to the
Published API ? (Assume that the changes are some
I completely agree with Nuwan. We should support updating published API
without increasing the version. Think about a banking industry. If there is
a critical bug in the mediation logic (lets say a masking logic), they
should be able to fix the issue in the same version transparently without
even
Hi Malintha,
Yes, the workflow you have mentioned is the same one I'm proposing too. My
only concern is on a new state, because implementing that is a bit
complicated and this particular use case is not very common and therefore
there's little ROI :).
Let's say we call this new state
Hi malintha,
in c5 we decided to keep in the gateway even in the create state for
purpose of creator's testing.
so this will be fine. but keeping additional info in the create state not
something good. because create state is the state very first state when an
api is create.
because of that I'm
Hi Nuwan,
On Fri, Mar 31, 2017 at 12:12 AM, Nuwan Dias wrote:
> Hi Pubudu,
>
> The API will reside on the Gateway irrespective of its state. So this
> action doesn't interrupt existing subscribers or existing consumers of the
> API. It only prevents any new subscribers from
Hi Prasanna,
On Fri, Mar 31, 2017 at 1:14 AM Prasanna Dangalla wrote:
> Hi Fazlan,
>
> On Thu, Mar 30, 2017 at 9:12 PM Fazlan Nazeem wrote:
>
> I don't think we should allow anyone to do changes to an already published
> API regardless of whether he/she is
Updating a technical information of a published API would result in
incompatibility issues in clients who already consumes this API and as
Fazlan pointed out I also think that any change should result in a new
version. If such a change is required, can't we alert / send an email to
subscribers and
Hi Fazlan,
On Thu, Mar 30, 2017 at 9:12 PM Fazlan Nazeem wrote:
> I don't think we should allow anyone to do changes to an already published
> API regardless of whether he/she is a creator or publisher.
> Any change done to an already published API is not the same API which
I don't think we should allow anyone to do changes to an already published
API regardless of whether he/she is a creator or publisher.
Any change done to an already published API is not the same API which was
published previously. Some of the changes could break the clients who are
already
Hi Pubudu,
The API will reside on the Gateway irrespective of its state. So this
action doesn't interrupt existing subscribers or existing consumers of the
API. It only prevents any new subscribers from seeing the API on the store
until republished.
I have thought about introducing a new LC
Hi Nuwan,
AFAIU, in this case, we are not addressing the original issue. Original
issue here is changes made by API developers should not be reflected in
Store and Gateway unless the API publisher publishes the API again. Please
correct me if I am wrong.
I don't think temporarily removing the
Hi Rukshan,
Since the API still exists in the database the subscriptions will be
preserved. Existing subscribers to the API will still see the API (under
subscriptions) as well. It will only be unavailable for new subscriptions
until re-published.
Thanks,
NuwanD.
On Thu, Mar 30, 2017 at 11:41
Hi Nuwan,
If we demote API back to create, state how we are going to handle
subscription already have? Are we going to disable them till the API get
publish again?
Also can we introduce or use the existing state to allow the API to be
update without un-publishing it. once it is done we can
Hi,
On API Manager, API Developers (!= publishers) aren't able to publish an
API to the Store or Gateway. But on API Manager version 2.1.0 and before,
if an API Developer makes an update to an API that is already published,
the changes made by the developer are immediately reflected on the Store
18 matches
Mail list logo