Hi,
I observed below in our product REST APIs.
*Publisher API*
In *publisher-api.yaml *base path is defined as
*/api/am/publisher/v1.0*
There are several micro services serving the publisher API hence, *@Path*
at the service level (base path) is defined as follows.
/api/am/publisher/v1.[\\d]+/apis
/api/am/publisher/v1.[\\d]+/endpoints
/api/am/publisher/v1.[\\d]+/applications
/api/am/publisher/v1.[\\d]+/environments
/api/am/publisher/v1.[\\d]+/export
/api/am/publisher/v1.[\\d]+/import
/api/am/publisher/v1.[\\d]+/labels
/api/am/publisher/v1.[\\d]+/policies
/api/am/publisher/v1.[\\d]+/subscriptions
/api/am/publisher/v1.[\\d]+/workflows
Due to above path definition, root collection does not have a @Path
annotation defined and @Path annotation for other resources are not
prefixed with the root collection.
ex:* /apis/{apiId*} is defined as
*/{apiId}*So there is an inconsistency in swagger definition and service
definition.
If we read path from swagger we get /apis/{apiId}
whereas from the service annotation we get it as /{apiId}
Same design has followed in store and admin apis as well.
This lead to a problem when doing the scope validation at the interceptor
level.
Because we validate scopes based on the resource path template that is
stored as what we read from swagger doc.
*Option 1*. We can get rid of this by doing an extra string manipulation
but IMHO it is not a good option as this path get hits for each and every
request coming to REST APIs and this is a deviation from what we can have
from the standard.
*Option 2*. If we can have a single Micro service to service entire API we
can define service path as /api/am/publisher/v1.[\\d] which will solve the
inconsistency.
Do we have extra advantages(performance etc.) to have separate micro
services?
In this use case(scope validation) what could be the best option to follow
from option 1 & 2?
WDYT?
Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture