[APIM 3.0] Product REST APIs service path definition

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[APIM 3.0] Product REST APIs service path definition

Ishara Cooray
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
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [APIM 3.0] Product REST APIs service path definition

Abimaran Kugathasan
Hi Ishara,

Some time back we agreed to create single micro service per Publisher, similarly, single micro service for Store and Admin REST APIs [1]. 

Going for single micro service is better as we will get advantages of lesser start up time, lesser memory footprint. We haven't tested the performance between these two approaches.


[1]: [Architecture] [APIM] [MSF4J] Reason for creating separate micro service for each path defined swagger

On Tue, Jun 6, 2017 at 12:19 PM, Ishara Cooray <[hidden email]> wrote:
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 : <a href="tel:+94%2077%20262%209512" value="+94772629512" target="_blank">+9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware



--
Thanks
Abimaran Kugathasan
Senior Software Engineer - API Technologies

Mobile : +94 773922820

    


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture