Hi Ishara, If we have an API with https://foo.bar/api/deparment/{deparment}/division/{ divisionId}/resource URL for a resource, a matching request will be like
https://foo.bar/api/deparment/engineering/division/computer/resource. In the above case, how we are going to validate whether an API exists? I see two problems there 1. Can't determine context, it can be either /api or /api/department, not sure how msf4j will retrieve this value 2. API have URI template, while a request has values for the template placeholders, how do we find whether there is a matching resource? Even if we create a tree structure with context and all the resources, we can't find the match unless it hits the gateway because of URL template placeholders. On Tue, Jan 31, 2017 at 11:56 AM, Ishara Cooray <[email protected]> wrote: > Hi Abhimaran, > > Sorry for delayed response. > Please find my comments in-line. > > How do we differentiate context and uriTemplates when a request sent? > > For example, if a request come with below URL > > https://foo.bar/test/api/request/resource > > How we are going to find which is context and which is urItemplate and > check the validity? > > These information could be obtained from *org.wso2.msf4j.request* at > interceptor level. And then it can be set in *PrivilegedCarbonContext* as > properties so that we can use them at the ValidationHandler. > > Also, don't we need to consider HTTP verb also? > Yes, we need to consider HTTP verb also at the time of resource validation. > > > 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, Jan 30, 2017 at 2:34 PM, Abimaran Kugathasan <[email protected]> > wrote: > >> Hi Ishara, >> >> How do we differentiate context and uriTemplates when a request sent? >> >> For example, if a request come with below URL >> >> https://foo.bar/test/api/request/resource >> >> How we are going to find which is context and which is urItemplate and >> check the validity? >> >> Also, don't we need to consider HTTP verb also? >> >> On Mon, Jan 30, 2017 at 2:28 PM, Lakmal Warusawithana <[email protected]> >> wrote: >> >>> +1 for the approach, this is lazy loading. >>> >>> Also we should support and give an option to full api load at startup. >>> Basically we should support lazy loading and full loading which can be >>> switch via a configuration. Full loading may important for some cases which >>> need first api call return fast, but not important of having auto scaling >>> of gateways and satisfy with manual scaling. >>> >>> BTW, images are not properly loading ... >>> >>> On Mon, Jan 30, 2017 at 2:06 PM, Ishara Cooray <[email protected]> wrote: >>> >>>> Hi, >>>> >>>> I am working on $Subject and following is the use case and the approach >>>> we are going to address. >>>> >>>> *Motivation:* >>>> In order to reduce the server startup time we thought of not loading >>>> the apis at the server startup. >>>> Then we need a way to validate api requests to avoid DOS attacks such >>>> as api requests with invalid context, passing to the api core level. >>>> >>>> *Solution:* >>>> Therefore we are planing to load summary of all apis(name, context, >>>> uriTemplates) into memory at server startup so that when an api request >>>> comes to the gateway it will first validate the availability of that >>>> api/resource. >>>> >>>> To get the api summary info there will be Rest Service in APIM core. >>>> >>>> >>>> >>>> >>>> For newly added apis we can update the in memory cache via a JMS Topic >>>> (later we can support for other message brokers as well) . >>>> >>>> >>>> >>>> Following components will be written to address these scenarios. >>>> >>>> >>>> 1. REST Service to retrieve API summary - *API Core* >>>> 2. APISummaryLoader to load APIsSummary at server startup - *GW* >>>> 3. JMS Topic receiver - *Core* >>>> 4. JSM topic listener - *GW* >>>> 5. APIContextValidationHandler - *GW* >>>> >>>> >>>> Thanks & Regards, >>>> Ishara Cooray >>>> Senior Software Engineer >>>> Mobile : +9477 262 9512 <+94%2077%20262%209512> >>>> WSO2, Inc. | http://wso2.com/ >>>> Lean . Enterprise . Middleware >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> Lakmal Warusawithana >>> Director - Cloud Architecture; WSO2 Inc. >>> Mobile : +94714289692 <+94%2071%20428%209692> >>> Blog : http://lakmalsview.blogspot.com/ >>> >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Thanks >> Abimaran Kugathasan >> Senior Software Engineer - API Technologies >> >> Email : [email protected] >> Mobile : +94 773922820 <+94%2077%20392%202820> >> >> <http://stackoverflow.com/users/515034> >> <http://lk.linkedin.com/in/abimaran> >> <http://www.lkabimaran.blogspot.com/> <https://github.com/abimarank> >> <https://twitter.com/abimaran> >> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > -- Thanks Abimaran Kugathasan Senior Software Engineer - API Technologies Email : [email protected] Mobile : +94 773922820 <http://stackoverflow.com/users/515034> <http://lk.linkedin.com/in/abimaran> <http://www.lkabimaran.blogspot.com/> <https://github.com/abimarank> <https://twitter.com/abimaran>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
