Hi all,
There is a requirement to add the following features to the Microgateway in
Future.
1.
Add multiple APIs to a project
2.
Publish APIs from Microgateway to Store
3.
Support fine-grained endpoint configurations based on resource level.
-
Ex. GET menu - <IP_1>
POST order - <IP_2>
Currently, when the “micro-gw setup” command is executed, it fails if the
project already exists and therefore we have no mechanism to add another
API to the same project.
Considering the developer first approach, the current folder structure of
the project is as follows.
Command:
*micro-gw setup <project_name> -oa <path_to_swagger_file> -e <endpoint>*
Folder Structure:
.
├── conf
│ └── deployment-config.toml
├── src
│ ├── PizzaShackAPI_1_0_0.bal
│ ├── extension_filter.bal
│ ├── listeners.bal
│ └── policies
│ ├── application_10PerMin.bal
│ ├── application_20PerMin.bal
│ ├── application_50PerMin.bal
│ ├── subscription_Bronze.bal
│ ├── subscription_Gold.bal
│ ├── subscription_Silver.bal
│ ├── subscription_Unauthenticated.bal
│ └── throttle_policy_initializer.bal
└── target
*Proposed Flow of the Process:*
*1. setup command*
*micro-gw setup <project_name> *
This is allowed and it will create the following folder structure
├── conf
│ └── deployment-config.toml
├── routes.yaml
├── src
│ └── policies
└── target
*micro-gw setup <project_name> -a <API_name> -oa <path_to_swagger_file> -e
<endpoint>*
In this case, another field is added called API_name. But it is possible to
identify the API name from the swagger file, but when the developer needs
to automate the process (using a shell script) it would be hard to continue
with.
Folder structure will look like this,
├── API_files
│ └── PizzaAPI
│ └── v_1.0.0
│ ├── meta_data.dat
│ └── pizzashackAPI.yaml
├── conf
│ └── deployment-config.toml
├── routes.yaml
├── src
│ └── policies
└── target
As you can see there is another folder added API_files. Inside that, there
is a folder called PizzaAPI which is provided by the developer using “-a”
flag. If the “-a” flag is not provided, We will read the swagger and name
accordingly. The version number is identified by reading the swagger file.
“pizzashackAPI.yaml” is the swagger definition of PizzaShackAPI. The
purpose behind saving the swagger is to publish the API to the store from
microgateway. Metadata file holds the metadata related to API. Other than
that the endpoint will be added to the routes.yaml with the corresponding
api_name and the version number. This endpoint is the basic endpoint for
the API. ( compare the difference with add-route command)
More importantly, there will not be a code generation operation at the
“setup” phase. In other words, there won’t be a “pizzashackAPI_1.0.0.bal”
file during this phase.
2. add-api command
As mentioned earlier, A project can either be “setup” with just one API
definition or without any API definition. To add more APIs, we need to
introduce the add command.
*micro-gw add-api -a <user_provided_API_name> -oa <path_to_swagger_file> -e
<endpoint*>
As mentioned in the setup command, the user can define his own api_name.
This is to add the capability to automate the execution (shell scripts).
For more details see the “add_route” command in the below section. But in
all the other operations, we will be continuing with api_name provided in
the swagger.
consider the following command,
micro-gw add-api -a DrinksAPI -oa drinks_swagger.json -e some_endpoint
├── API_files
│ ├── DrinksAPI
│ │ └── v_1.0.0
│ │ ├── drinksAPI.yaml
│ │ └── meta_data.dat
│ └── PizzaAPI
│ └── v_1.0.0
│ ├── meta_data.dat
│ └── pizzashackAPI.yaml
├── conf
│ └── deployment-config.toml
├── routes.yaml
├── src
│ └── policies
└── target
It can be observed that still there is no code generation (bal file
generation) has happened.
3. add-route command
* micro-gw add-route -a <user_provided_api_name> -v <version> <http_method>
<resource_name> -e <endpoint>*
We have added a basic endpoint while setting up the API. This command is to
provide separate endpoints based on resource level. <http_method> would be
something like “GET”, “POST” etc. and resource_name would be something like
“menu”. These details would be added to the routes.yaml as well.
4. build command
micro-gw build <project_name>
This is the same existing command. The difference is that code generation
and compilation both happen at this phase. (Previously code generation
happened at the “setup” phase.) In this case, pizzashackAPI_1.0.0.bal file
and drinksAPI_1.0.0.bal both will be saved in the src directory. Target
directory will have all the components which will be required to run the
microgateway.
5. delete_api command
micro-gw delete-api -a <API_name> -v <API_version>
Since we are supporting add_api command, we need to support delete_api
command as well.
6. list_apis command
micro-gw list_apis
This will list down all the APIs with their available versions. (API name
would be the name of that folder corresponding to the API)
7. register command
micro-gw register -a <API_name> -v <API_version>
This command will publish the API in Store. Since we have the swagger file
saved in the directory, we can use the Publisher API.
Please consider that the command names and the arguments are not finalized
yet. But this is the expected way to accomplish the task.
As the initial step, the setup command and build command will be changed as
mentioned. In addition, the register command will be implemented.
Regards,
Viraj
--
*Viraj Salaka Gamage* | Software Engineer | WSO2 Inc.
+94 710 618 178
GET INTEGRATION AGILE
Integration Agility for Digitally Driven Business
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
