Hi All, I did a rough implementation of the method I communicated in the previous mail (of making a pseudo-service out of the each rest API), and the concept "works" but it kind of looks like a "hack" at the end of the day.
I've listed down a few reasons, as to why this approach seems this way. 1. The barrier between API and Proxy Service now seems murkier than ever 2. When going by this approach APIs need to be accessed with a "/services/<CONTEXT>" url pattern. 3. I had to re-implement the proxy service instantiating methods leaving out most of the logic, in-order to create pseudo-services 4. We will not be able to have a Rest API and Proxy Service with the same name, at a given point of time (Since the AxisConfiguration will maintain an entry for the pseudo-service created in the API's stead) 5. Since, in the code "context" value specified in the URL will be used to look up the Service. API name and Context needs to be the same. What do you all think? What would be the best way to achieve $subject? Thanks, Ruwan Yatawara Ruwan Yatawara Software Engineer, WSO2 Inc. lean . enterprise . middleware email : [email protected] mobile : +94 77 9110413 www: :http://wso2.com On Mon, Jul 1, 2013 at 11:15 PM, Ruwan Yatawara <[email protected]> wrote: > Hi All, > > We are trying to introduce transport level access restrictions to APIs. As > is already there in Proxy-Services, we seek to introduce a transport > attribute to the API configuration and filter API access via same. > > However when looking through the Syanpse code, i came to the understanding > that, transport validation is done via the axis2 code (It's the same block > of code) for both Proxy Services and APIs. Before dispatching a call to > Axis2, Synapse will verify whether the message context includes a service. > When it comes to APIs, in which case there isn't an attached service, > Synapse will specify the default "__SynapseService" as the service. > > Because of this, when it comes down to the Axis level, Proxy Service and > Rest API calls will both be treated as services (since both have services > assign to them). When Service#getExposedTransports method is called, whilst > the proxy service will relay back transports configured for that "specific" > service, Rest APIs would always return the exposed transports for the > "default" service (which are always HTTP & HTTPS). > > As a workaround for this I was thinking, maybe we can constitute some sort > of "Pseudo-Service" (Since it is anyhow being treated at Axis level as a > Service) out of each Rest API, and maintain a Deployer that will set/update > parameters like "ExposedTransports" that may in turn be accessed via Axis. > > I'm not entirely sure if this is the right thing to do. > > Please feel free to weigh in your thoughts. > > > Thanks, > > Ruwan Yatawara >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
