Hi Chamalee,
This feature has been implemented after the ESB 500 release and it should
be available in EI.
You need to add following processors under HttpGetRequestProcessors in
carbon.xml to get feature to work.
<Processor>
<Item>swagger.json</Item>
<Class>org.wso2.carbon.
mediation.transport.handlers.requestprocessors.swagger.
format.SwaggerJsonProcessor</Class>
</Processor>
<Processor>
<Item>swagger.yaml</Item>
<Class>org.wso2.carbon.mediation.transport.handlers.
requestprocessors.swagger.format.SwaggerYamlProcessor</Class>
</Processor>
Please refer JIRA[1] for more information.
[1]. https://wso2.org/jira/browse/ESBJAVA-4936
Thanks,
Vijitha.
On Thu, Sep 14, 2017 at 4:49 PM, Chamalee De Silva <[email protected]>
wrote:
> Hi Maheeka and ESB team,
>
> Is $Subject available in ESB 5.0.0 ?
> Do we have any documentation on $Subject that we can use to try swagger
> support on ESB REST APIs ?
> I found mail thread [1] and JIRA [2] related to this.
>
> Appreciate your help.
>
> [1] Integration Cloud - ESB on Cloud
> [2] https://wso2.org/jira/browse/ESBJAVA-3709
>
>
>
> Thanks,
> Chamalee
>
> On Thu, Sep 29, 2016 at 11:21 AM, Joseph Fonseka <[email protected]> wrote:
>
>> Hi Jagath
>>
>> It is the same case weather we provide users to add swagger
>> annotations/notes to define additional parameters in synapse. If we have
>> such approch we can use it to define the path parameter type.
>>
>> Since we are supporting above in the next iteration we could resolve to
>> create the path parameter with a default type preferably *string* since it
>> is less restrictive.
>>
>> Also please note swagger spec do not support full URI template
>> specification.
>>
>> Thanks
>> Jo
>>
>> On Tue, Sep 27, 2016 at 11:12 AM, Jagath Sisirakumara Ariyarathne <
>> [email protected]> wrote:
>>
>>> Hi,
>>>
>>> While implementing swagger definition for uri-template based APIs, we
>>> have following problem.
>>>
>>> If we have a template like "/view/{symbol}", we need to define "symbol"
>>> as a parameter in swagger definition. According to the swagger spec for
>>> parameters[1], if it is a query or path parameter, then it is required to
>>> have a type (string, number etc) for this parameter. But this information
>>> is not available in existing synapse configurations of APIs. The possible
>>> option is to provide all parameters as "string" as Maheeka mentioned
>>> earlier.
>>>
>>> Appreciate any thoughts on this.
>>>
>>> [1] - http://swagger.io/specification/#parameterObject
>>>
>>> Thanks.
>>>
>>> On Tue, Sep 27, 2016 at 5:38 AM, Jagath Sisirakumara Ariyarathne <
>>> [email protected]> wrote:
>>>
>>>> Hi All,
>>>>
>>>> I have completed initial implementation for url-mapping based APIs.
>>>> Attached sample API and its definitions. I am further working on supporting
>>>> uri-templates based definitions.
>>>>
>>>> Thanks.
>>>>
>>>> On Thu, Sep 22, 2016 at 2:09 PM, Jagath Sisirakumara Ariyarathne <
>>>> [email protected]> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> In this particular implementation for Integration Cloud, we planned to
>>>>> go with an extension which uses existing information in synapse
>>>>> configurations without updating synapse code base. Therefore as Maheeka
>>>>> mentioned in [1], we are going to provide limited information at initial
>>>>> phase. But in long run, we need to extend this to store all required API
>>>>> definitions in synapse configurations.
>>>>>
>>>>> [1] - https://gist.github.com/maheeka/ec23751f21d8d7d5abaa4f9130f233f2
>>>>>
>>>>> Thanks.
>>>>>
>>>>> On Thu, Sep 22, 2016 at 8:23 AM, Joseph Fonseka <[email protected]>
>>>>> wrote:
>>>>>
>>>>>> Hi
>>>>>>
>>>>>> On Tue, Sep 20, 2016 at 4:18 PM, Maheeka Jayasuriya <[email protected]
>>>>>> > wrote:
>>>>>>
>>>>>>>
>>>>>>> Please note these changes were done based on the level of
>>>>>>> information we have on the API by referring to it's configuration. For
>>>>>>> example, we do not have a way of determining the request format or uri
>>>>>>> parameter types and content-types of the API. This will require further
>>>>>>> digging and analyzing on the configuration.
>>>>>>>
>>>>>>
>>>>>> Have you consider adding additional information as annotations/notes
>>>>>> in the config. AFAIK we do not have a config to add annotations so
>>>>>> currently we can define them as properties but going forward may be we
>>>>>> can
>>>>>> add some way to annotate synapse.
>>>>>>
>>>>>> In the longer run mostly synapse APIs will be generated out of
>>>>>> swagger definitions thus having the ability to contain all the API
>>>>>> definition information in the synapse file would be important.
>>>>>>
>>>>>> Thanks
>>>>>> Jo
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Find the diff of these changes done to the Swagger definition at [4]
>>>>>>>
>>>>>>> To get the required information from the Rest API configuration we
>>>>>>> can invoke RestApiAdminServices's getApiByName operation which returns
>>>>>>> the
>>>>>>> following response [5] for an API created that has the PetStore
>>>>>>> resources.
>>>>>>> We can identify the methods and uri-template and mappings from this
>>>>>>> response.
>>>>>>>
>>>>>>> Please let know your thoughts.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Maheeka
>>>>>>>
>>>>>>> [1] http://petstore.swagger.io/#/pet
>>>>>>> [2] https://gist.github.com/maheeka/4eaedd2e2e0765959a4166865bf9adf9
>>>>>>> [3] https://gist.github.com/maheeka/ec23751f21d8d7d5abaa4f9130f233f2
>>>>>>> [4] https://www.diffchecker.com/xEu0NSNz
>>>>>>> [5] <soapenv:Envelope xmlns:soapenv="http://schemas.
>>>>>>> xmlsoap.org/soap/envelope/">
>>>>>>> <soapenv:Body>
>>>>>>> <ns:getApiByNameResponse xmlns:ns="http://org.apache.axis2/xsd
>>>>>>> ">
>>>>>>> <ns:return xsi:type="ax2476:APIData" xmlns:ax2476="
>>>>>>> http://api.rest.carbon.wso2.org/xsd"; xmlns:xsi="http://www.w3.org/2
>>>>>>> 001/XMLSchema-instance">
>>>>>>> <ax2476:artifactContainerName xsi:nil="true"/>
>>>>>>> <ax2476:context>/pet</ax2476:context>
>>>>>>> <ax2476:fileName>PetstoreAPI.xml</ax2476:fileName>
>>>>>>> <ax2476:host xsi:nil="true"/>
>>>>>>> <ax2476:isEdited>false</ax2476:isEdited>
>>>>>>> <ax2476:name>PetstoreAPI</ax2476:name>
>>>>>>> <ax2476:port>-1</ax2476:port>
>>>>>>> <ax2476:resources xsi:type="ax2476:ResourceData">
>>>>>>> <ax2476:contentType xsi:nil="true"/>
>>>>>>> <ax2476:faultSeqXml xsi:nil="true"/>
>>>>>>> <ax2476:faultSequenceKey xsi:nil="true"/>
>>>>>>> <ax2476:inSeqXml xsi:nil="true"/>
>>>>>>> <ax2476:inSequenceKey xsi:nil="true"/>
>>>>>>> <ax2476:methods>POST</ax2476:methods>
>>>>>>> <ax2476:methods>PUT</ax2476:methods>
>>>>>>> <ax2476:outSeqXml xsi:nil="true"/>
>>>>>>> <ax2476:outSequenceKey xsi:nil="true"/>
>>>>>>> <ax2476:protocol>0</ax2476:protocol>
>>>>>>> <ax2476:uriTemplate xsi:nil="true"/>
>>>>>>> <ax2476:urlMapping>/</ax2476:urlMapping>
>>>>>>> <ax2476:userAgent xsi:nil="true"/>
>>>>>>> </ax2476:resources>
>>>>>>> <ax2476:resources xsi:type="ax2476:ResourceData">
>>>>>>> <ax2476:contentType xsi:nil="true"/>
>>>>>>> <ax2476:faultSeqXml xsi:nil="true"/>
>>>>>>> <ax2476:faultSequenceKey xsi:nil="true"/>
>>>>>>> <ax2476:inSeqXml xsi:nil="true"/>
>>>>>>> <ax2476:inSequenceKey xsi:nil="true"/>
>>>>>>> <ax2476:methods>POST</ax2476:methods>
>>>>>>> <ax2476:methods>DELETE</ax2476:methods>
>>>>>>> <ax2476:methods>GET</ax2476:methods>
>>>>>>> <ax2476:outSeqXml xsi:nil="true"/>
>>>>>>> <ax2476:outSequenceKey xsi:nil="true"/>
>>>>>>> <ax2476:protocol>0</ax2476:protocol>
>>>>>>> <ax2476:uriTemplate>/{petId}</ax2476:uriTemplate>
>>>>>>> <ax2476:urlMapping xsi:nil="true"/>
>>>>>>> <ax2476:userAgent xsi:nil="true"/>
>>>>>>> </ax2476:resources>
>>>>>>> <ax2476:statisticsEnable>false</ax2476:statisticsEnable>
>>>>>>> <ax2476:tracingEnable>false</ax2476:tracingEnable>
>>>>>>> </ns:return>
>>>>>>> </ns:getApiByNameResponse>
>>>>>>> </soapenv:Body>
>>>>>>> </soapenv:Envelope>
>>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Maheeka Jayasuriya
>>>>>>> Senior Software Engineer
>>>>>>> Mobile : +94777750661
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> --
>>>>>> *Joseph Fonseka*
>>>>>> WSO2 Inc.; http://wso2.com
>>>>>> lean.enterprise.middleware
>>>>>>
>>>>>> mobile: +94 772 512 430
>>>>>> skype: jpfonseka
>>>>>>
>>>>>> * <http://lk.linkedin.com/in/rumeshbandara>*
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Jagath Ariyarathne
>>>>> Technical Lead
>>>>> WSO2 Inc. http://wso2.com/
>>>>> Email: [email protected]
>>>>> Mob : +94 77 386 7048
>>>>> <http://wso2.com/signature>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Jagath Ariyarathne
>>>> Technical Lead
>>>> WSO2 Inc. http://wso2.com/
>>>> Email: [email protected]
>>>> Mob : +94 77 386 7048
>>>> <http://wso2.com/signature>
>>>>
>>>
>>>
>>>
>>> --
>>> Jagath Ariyarathne
>>> Technical Lead
>>> WSO2 Inc. http://wso2.com/
>>> Email: [email protected]
>>> Mob : +94 77 386 7048
>>> <http://wso2.com/signature>
>>>
>>
>>
>>
>> --
>>
>> --
>> *Joseph Fonseka*
>> WSO2 Inc.; http://wso2.com
>> lean.enterprise.middleware
>>
>> mobile: +94 772 512 430
>> skype: jpfonseka
>>
>> * <http://lk.linkedin.com/in/rumeshbandara>*
>>
>>
>> _______________________________________________
>> Dev mailing list
>> [email protected]
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> Thanks & Regards,
>
> *Chamalee De Silva*
> Software Engineer
> *WS**O2* Inc. :http://wso2.com/
>
> Office :- *+94 11 2145345 <%2B94%2011%202145345>*
> mobile :- *+94 7 <%2B94%2077%202782039>1 4315942*
>
>
> _______________________________________________
> Dev mailing list
> [email protected]
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>
--
Vijitha Ekanayake
Software Engineer*, *WSO2, Inc.; http://wso2.com/
Mobile : +94 777 24 73 39 | +94 718 74 44 08
lean.enterprise.middleware
_______________________________________________
Dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/dev
