Please refer new thread[1] in architecture group which discusses the issue with @Path annotation..
[1] [APIM 3.0] Product REST APIs service path definition Thanks & Regards, Ishara Cooray Senior Software Engineer Mobile : +9477 262 9512 WSO2, Inc. | http://wso2.com/ Lean . Enterprise . Middleware On Tue, Jun 6, 2017 at 12:39 PM, Sanjeewa Malalgoda <[email protected]> wrote: > I'm not sure its correct design or not. Because if we consider APIsApi > then root path should be apis and in resource level we have http verbs and > parameters. If we enable this /apis will be duplicate at each resource > level. > > Thanks, > sanjeewa. > > On Tue, Jun 6, 2017 at 6:11 AM, Ishara Cooray <[email protected]> wrote: > >> >> This happens because, in our rest api generated code, we do not have >> @Path annotation is defined for root collection, >> >> For example* /apis* is defined as, >> >> @GET >>> >>> @Consumes({ "application/json" }) >>> @Produces({ "application/json" }) >>> @io.swagger.annotations.ApiOperation(value = "Retrieve/Search APIs ", notes >>> = "This operation provides you a list of available APIs qualifying under a >>> given search condition. Each retrieved API is represented with a minimal >>> amount of attributes. If you want to get complete details of an API, you >>> need to use **Get details of an API** operation. ", response = >>> APIListDTO.class, tags={ "API (Collection)", }) >>> @io.swagger.annotations.ApiResponses(value = { >>> @io.swagger.annotations.ApiResponse(code = 200, message = "OK. List of >>> qualifying APIs is returned. ", response = APIListDTO.class), >>> >>> @io.swagger.annotations.ApiResponse(code = 304, message = "Not >>> Modified. Empty body because the client has already the latest version of >>> the requested resource (Will be supported in future). ", response = >>> APIListDTO.class), >>> >>> @io.swagger.annotations.ApiResponse(code = 406, message = "Not >>> Acceptable. The requested media type is not supported ", response = >>> APIListDTO.class) }) >>> public Response apisGet.... >>> >>> >> */apis/{apiId} *is defined as >> >> @PUT >>> @Path("/{apiId}") >>> @Consumes({ "application/json" }) >>> @Produces({ "application/json" }) >>> @io.swagger.annotations.ApiOperation(value = "Update an API", notes = "This >>> operation can be used to update an existing API. But the properties `name`, >>> `version`, `context`, `provider`, `state` will not be changed by this >>> operation. ", response = APIDTO.class, tags={ "API (Individual)", }) >>> @io.swagger.annotations.ApiResponses(value = { >>> >>> >> >> And class level @Path is defined as below. >> >>> @Path("/api/am/publisher/v1.[\\d]+/apis") >>> >>> *@Sanjeewa,* >> >> Can we change the class level @Path to "/api/am/publisher/v1.[\\d]+" >> >> so that */apis* can be appended in resource level path templates, which >> will enable us to add @Path annotation to root collection as well. >> >> >> Thanks & Regards, >> Ishara Cooray >> Senior Software Engineer >> Mobile : +9477 262 9512 <077%20262%209512> >> WSO2, Inc. | http://wso2.com/ >> Lean . Enterprise . Middleware >> >> On Mon, Jun 5, 2017 at 9:29 PM, Thusitha Thilina Dayaratne < >> [email protected]> wrote: >> >>> Hi Ishara, >>> >>> Since this is direct Java reflection call, ideally it shouldn't return >>> null if there is a @Path annotation. >>> That seems strange. >>> >>> Thanks >>> Thusitha >>> >>> On Mon, Jun 5, 2017 at 4:58 AM, Ishara Cooray <[email protected]> wrote: >>> >>>> You can access the actual method that will get invoke at the >>>> Interceptor level >>>> e.g. request.getProperty("method");[1] So then you can get the @Path >>>> value of the method and compare that with the request.getUri(). >>>> >>>> Hi Thusitha, >>>> >>>> This worked for me. >>>> However, for resource paths such as "*/apis*" @Path returns null where >>>> as "*/apis/{apiId}*" returns the correct value. >>>> >>>> It seems very first collection returns null for @Path annotation. >>>> Is it an expected behavior? >>>> >>>> >>>> >>>> >>>> Thanks & Regards, >>>> Ishara Cooray >>>> Senior Software Engineer >>>> Mobile : +9477 262 9512 <+94%2077%20262%209512> >>>> WSO2, Inc. | http://wso2.com/ >>>> Lean . Enterprise . Middleware >>>> >>>> On Mon, May 29, 2017 at 10:06 PM, Thusitha Thilina Dayaratne < >>>> [email protected]> wrote: >>>> >>>>> Hi Ishara, >>>>> >>>>> You can access the actual method that will get invoke at the >>>>> Interceptor level >>>>> e.g. request.getProperty("method");[1] So then you can get the @Path >>>>> value of the method and compare that with the request.getUri(). >>>>> >>>>> [1] - https://github.com/wso2/msf4j/blob/v2.3.0-m2/core/src/main >>>>> /java/org/wso2/msf4j/internal/router/HttpMethodInfo.java#L174 >>>>> >>>>> Thanks >>>>> Thusitha >>>>> >>>>> On Mon, May 29, 2017 at 1:51 AM, Ishara Cooray <[email protected]> >>>>> wrote: >>>>> >>>>>> Ths usecase behind this is, >>>>>> >>>>>> we have scopes defined in apim product REST APIs for each resource >>>>>> path as below. >>>>>> >>>>>> /apis/{apiId}: >>>>>> >>>>>> #----------------------------------------------------- >>>>>> >>>>>> # Retrieve the details of an API definition >>>>>> >>>>>> #----------------------------------------------------- >>>>>> >>>>>> get: >>>>>> >>>>>> x-scope: apim:api_view >>>>>> >>>>>> x-wso2-curl: "curl -k -H \"Authorization: Bearer >>>>>> ae4eae22-3f65-387b-a171-d37eaa366fa8\" https://127.0.0.1:9443/api/am/ >>>>>> publisher/v1.0/apis/7a2298c4-c905-403f-8fac-38c73301631f" >>>>>> >>>>>> ...... >>>>>> >>>>>> >>>>>> We are keeping track of these resource to scope mapping and at the >>>>>> time of a new request, we need to validate the scope. >>>>>> >>>>>> But, the request coming with a >>>>>> value(206e1b0b-a48e-47c9-95d0-3eb85544cf2e) >>>>>> for the variable(apiId), hence unable to find the resource template to >>>>>> match unless we do a string manipulation(we are maintaining a map for the >>>>>> resource to scope mapping). >>>>>> >>>>>> >>>>>> We better avoid string manipulations as much as possible because this >>>>>> will take place in gateway. >>>>>> >>>>>> >>>>>> Therefore need to check the possibility of supporting this from MSF4J >>>>>> level so that we can get template info from the Request object itself. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Thanks & Regards, >>>>>> Ishara Cooray >>>>>> Senior Software Engineer >>>>>> Mobile : +9477 262 9512 <+94%2077%20262%209512> >>>>>> WSO2, Inc. | http://wso2.com/ >>>>>> Lean . Enterprise . Middleware >>>>>> >>>>>> On Mon, May 29, 2017 at 12:40 PM, Ishara Cooray <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> We have a requirement to identify the request template for a given >>>>>>> http request. >>>>>>> >>>>>>> For example, >>>>>>> *Req: * >>>>>>> /api/am/publisher/v1.0/apis/206e1b0b-a48e-47c9-95d0-3eb85544cf2e >>>>>>> >>>>>>> *Req path:* >>>>>>> /apis/206e1b0b-a48e-47c9-95d0-3eb85544cf2e >>>>>>> >>>>>>> *Need *to identify corresponding *template as * >>>>>>> apis/{apiId} >>>>>>> >>>>>>> Is there a way to get this info from the MSF4J level? >>>>>>> >>>>>>> >>>>>>> Thanks & Regards, >>>>>>> Ishara Cooray >>>>>>> Senior Software Engineer >>>>>>> Mobile : +9477 262 9512 <+94%2077%20262%209512> >>>>>>> WSO2, Inc. | http://wso2.com/ >>>>>>> Lean . Enterprise . Middleware >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Thusitha Dayaratne >>>>> WSO2 Inc. - lean . enterprise . middleware | wso2.com >>>>> >>>>> Mobile +94712756809 <+94%2071%20275%206809> >>>>> Blog alokayasoya.blogspot.com >>>>> About http://about.me/thusithathilina >>>>> <http://wso2.com/signature> >>>>> >>>>> >>>> >>> >>> >>> -- >>> Thusitha Dayaratne >>> WSO2 Inc. - lean . enterprise . middleware | wso2.com >>> >>> Mobile +94712756809 <+94%2071%20275%206809> >>> Blog alokayasoya.blogspot.com >>> About http://about.me/thusithathilina >>> <http://wso2.com/signature> >>> >>> >> > > > -- > > *Sanjeewa Malalgoda* > WSO2 Inc. > Mobile : +94713068779 <+94%2071%20306%208779> > > <http://sanjeewamalalgoda.blogspot.com/>blog :http://sanjeewamalalgoda. > blogspot.com/ <http://sanjeewamalalgoda.blogspot.com/> > > >
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
