On Mon, Feb 25, 2019 at 3:31 PM Arshardh Ifthikar <[email protected]> wrote:
> Hi all, > > Shall we also give the option for a developer to specify the default API > version. > We will have to come up with a mechanism to support this. It would be > great if we can add this as a flag or introduce a new command, instead of > altering the swagger file. > This was a requirement when we first released the developer-first approach. > Yes +1. Since this concept is a WSO2 specific thing we can't add it to the OAS file IMO. This is one use-case for bringing up a api meta-data file. There should be a specific entry in this file to indicate that a given API should be exposed as the default version API. > > Thanks, > Arshardh > > On Mon, Feb 25, 2019 at 10:15 AM Nuwan Dias <[email protected]> wrote: > >> >> >> On Sun, Feb 24, 2019 at 3:20 PM Pubudu Gunatilaka <[email protected]> >> wrote: >> >>> Hi, >>> >>> On Sat, Feb 23, 2019 at 1:01 PM Viraj Gamage <[email protected]> wrote: >>> >>>> 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. >>>> >>> >>> We have the label concept in APIM to group APIs and use that label to >>> generate the microgateway. But when moving with dev first approach, we >>> can't use this approach. >>> >> >> I wonder whether if its even required in this case. The labels are >> attached to APIs on "API Manager". And all APIs with the same label are put >> into the same project anyway. In the developer first approach you have a >> native way of putting APIs into the same project, so labels become >> obsolete. >> >>> >>>> 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>* >>>> >>>> >>> How do we handle functions? We may need a mechanism to provide a set of >>> functions for mediations and match those with the relevant resources. There >>> can be instances where we need to define multiple endpoints. Then we would >>> need a way to define those multiple endpoints. >>> >> >> Yes, we would need something like micro-gw add route -e "endpoint" -f >> "function_name". >> >>> 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 >>>> >>> >>> I guess we are validating the routes.yaml as we cannot have the same >>> context for multiple APIs. >>> >> >> In this case the routes are added by the micro-gw developer toolkit (not >> by hand). So ideally it won't have any errors. >> >> >>> ├── 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*> >>>> >>>> >>> I think in all the cases we have to specifically provide the project >>> name when executing the tool kit commands. If you look at the below >>> commands, you will need the relevant project. Shall we come up with a >>> command like below? >>> >>> micro-gw set-project <project_name> >>> >> >> Yes, +1. >> >>> >>> Then we don't need to provide the project name every time. >>> >>>> >>>> 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 >>>> >>> >>> >>> Thank you! >>> -- >>> *Pubudu Gunatilaka* >>> Committer and PMC Member - Apache Stratos >>> Associate Technical Lead >>> WSO2, Inc.: http://wso2.com >>> mobile : +94774078049 <%2B94772207163> >>> >>> >> >> -- >> *Nuwan Dias* | Director | WSO2 Inc. >> (m) +94 777 775 729 | (e) [email protected] >> [image: Signature.jpg] >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> > > > -- > *Arshardh Ifthikar* > Software Engineer | WSO2 Inc. > > Email: [email protected] > Mobile: +94719806525 > Web: http://wso2.com > > <http://wso2.com/signature> > -- *Nuwan Dias* | Director | WSO2 Inc. (m) +94 777 775 729 | (e) [email protected] [image: Signature.jpg]
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
