Hi Nuwan,
I agree to you. I also have done the second option calling
jaggery REST endpoint to publish the REST API. I tested using a menu item
click on it will publish the REST API after Greg server start up. User who
has certain permission may publish the REST API if not published under the
same tenant.
Thanks,
On Fri, Jul 19, 2013 at 3:20 PM, Nuwan Dias <nuw...@wso2.com> wrote:
> On Fri, Jul 19, 2013 at 2:59 PM, Senaka Fernando <sen...@wso2.com> wrote:
>
>> Hi Nuwan,
>>
>> I think the check at start-up is not going to be very expensive. During
>> server start-up we do several checks for services too. It will become
>> expensive if you try to do the same for all tenants of course. Such needs
>> to happen when the tenant gets loaded. That's the standard pattern which is
>> followed by all deployers. I believe API Mgt needs a similar concept here.
>>
>> Understood. There is however another problem that will arise if we're
> going to create APIs at server startup. See explanation below.
>
> There are two ways that we can create the API.
> 1) Create the registry artifact and database entry.
> 2) Call the jaggery REST endpoint for creating the API.
>
> Both options will work with embedded API Management. But option 1 will not
> work with external API Management since we do not know the details of the
> API registry and DB. So when going with external API Management, we will
> have to go with option 2. Therefore it would be better to stick to option 2
> for both cases since it'll be cleaner and have less complexity. For option
> 2 to work, the server should already be started. Therefore creating APIs at
> server startup in this manner would not be possible AFAIK.
>
> Thanks,
> NuwanD.
>
> Thanks,
>> Senaka.
>>
>>
>> On Fri, Jul 19, 2013 at 2:48 PM, Nuwan Dias <nuw...@wso2.com> wrote:
>>
>>> On Fri, Jul 19, 2013 at 12:35 PM, Lakmali Baminiwatta
>>> <lakm...@wso2.com>wrote:
>>>
>>>> Hi Nuwan,
>>>>
>>>>
>>>> On 19 July 2013 12:19, Nuwan Dias <nuw...@wso2.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I think the API should initially be in a created state rather than
>>>>> being in a published state. The admin or whoever responsible should
>>>>> publish
>>>>> it through the publisher.
>>>>>
>>>>> We also need to make this a generic solution so that it works even
>>>>> with external API Management. When the API is added to the registry, it
>>>>> will be visible on the publisher (external). And when the admin goes and
>>>>> publishes it, the API will then be deployed onto the Store and Gateway.
>>>>>
>>>>
>>>> +1. Agree.
>>>>
>>>> Thanks,
>>>> Lakmali
>>>>
>>>>>
>>>>> Thanks,
>>>>> NuwanD.
>>>>>
>>>>>
>>>>> On Fri, Jul 19, 2013 at 12:10 PM, Lakmali Baminiwatta <
>>>>> lakm...@wso2.com> wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> We have completed the implementation of the Embedded APIM
>>>>>> functionality, to manage GREG Rest APIs. We need to clarify how are we
>>>>>> going to publish the GREG Rest API. Publishing the API includes following
>>>>>> tasks,
>>>>>>
>>>>>> - Add the API artifact to the registry
>>>>>> - Add the API to the APIM database
>>>>>>
>>>>>> So we have three options to publish the API.
>>>>>>
>>>>>> 1. Admin manually create the API and publish through API Publisher
>>>>>> app. (This is what we do at the moment)
>>>>>>
>>>>>
>>> Since we're publishing internal Product APIs here, this would not be a
>>> good option since users will not know what to publish and what information
>>> to enter.
>>>
>>>>
>>>>>> 2. Publish the API at the server startup.
>>>>>> But since this is a one time operation, there will be
>>>>>> an overhead at each server startup, in checking whether the API has
>>>>>> already
>>>>>> published.
>>>>>>
>>>>>
>>> Yes, as mentioned it would be an overhead to check whether the necessary
>>> APIs have been published at server startup.
>>>
>>>>
>>>>>> 3. Publish the API at the GREG pack build time.
>>>>>>
>>>>>
>>> This will work with embedded API Management but this is not a solution
>>> when going with External API Management.
>>>
>>>>
>>>>>> What would be the best option to procede with?
>>>>>>
>>>>>
>>> Looking at the given options what I feel best is to have some kind of an
>>> Admin page where the Product's internal APIs are listed and and
>>> administrative user has the option of publishing them. Since we're talking
>>> about internal production APIs, it would also be fine to publish them
>>> directly rather than it first being in a created state.
>>>
>>> Thanks,
>>> NuwanD.
>>>
>>>>
>>>>>> Thanks,
>>>>>> Lakmali
>>>>>>
>>>>>> --
>>>>>> Lakmali Baminiwatta*
>>>>>> *
>>>>>> Software Engineer
>>>>>> WSO2, Inc.: http://wso2.com
>>>>>> lean.enterprise.middleware
>>>>>> mobile: +94 71 2335936
>>>>>> blog : lakmali.com
>>>>>> *
>>>>>> *
>>>>>>
>>>>>> _______________________________________________
>>>>>> Dev mailing list
>>>>>> Dev@wso2.org
>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Nuwan Dias
>>>>>
>>>>> Senior Software Engineer - WSO2, Inc. http://wso2.com
>>>>> email : nuw...@wso2.com
>>>>> Phone : +94 777 775 729
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Lakmali Baminiwatta*
>>>> *
>>>> Software Engineer
>>>> WSO2, Inc.: http://wso2.com
>>>> lean.enterprise.middleware
>>>> mobile: +94 71 2335936
>>>> blog : lakmali.com
>>>> *
>>>> *
>>>>
>>>
>>>
>>>
>>> --
>>> Nuwan Dias
>>>
>>> Senior Software Engineer - WSO2, Inc. http://wso2.com
>>> email : nuw...@wso2.com
>>> Phone : +94 777 775 729
>>>
>>> _______________________________________________
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>> * <http://us13.wso2con.com/>
>> *
>> *
>> *
>> *Senaka Fernando*
>> Senior Technical Lead; WSO2 Inc.; http://wso2.com*
>> Member; Apache Software Foundation; http://apache.org
>>
>> E-mail: senaka AT wso2.com
>> **P: +1 408 754 7388; ext: 51736*; *M: +94 77 322 1818
>> Linked-In: http://linkedin.com/in/senakafernando
>>
>> *Lean . Enterprise . Middleware
>>
>
>
>
> --
> Nuwan Dias
>
> Senior Software Engineer - WSO2, Inc. http://wso2.com
> email : nuw...@wso2.com
> Phone : +94 777 775 729
>
> _______________________________________________
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>
_______________________________________________
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev
