+1 Handling this logic at Inbound EP level will give us the flexibility for more use cases and future changes as well.
Thanks. On Fri, Jun 26, 2015 at 4:25 PM, Kasun Indrasiri <[email protected]> wrote: > Hi, > > In the current HTTP Inbound EP impl, the message dispatching occurs as > follows. > > - All proxy services and APIs are exposed on default HTTP port (8280). > - We can create a HTTP inbound EP that listens for request on a given port > (say 6060). Once we do that, all the proxy services and APIs are also > available via that port (i.e.: You can access the same proxy service via > 8280 or 6060). > - Likewise as you keep on creating inbound EPs, the existing proxies and > APIs will be exposed on those ports. > - Using a service parameter (inbound.only=true), we block any request that > comes to a proxy service and only expose that through inbound endpoints. > > IMO, above behavior may be useful in certain use cases, but there can be a > requirement which the user doesn't want to expose all proxy services/api > through all the available HTTP endpoints. Hence, it is required to control > the dispatching logic at Inbound EP level, so that we can specify the > allowed services and APIs (as a pattern matching expression) when we define > an inbound EP. > > Any thoughts? > > Thanks, > > -- > Kasun Indrasiri > Software Architect > WSO2, Inc.; http://wso2.com > lean.enterprise.middleware > > cell: +94 77 556 5206 > Blog : http://kasunpanorama.blogspot.com/ > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Jagath Ariyarathne Technical Lead WSO2 Inc. http://wso2.com/ Email: [email protected] Mob : +94 77 386 7048
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
