I am evaluating WSO2 G-REG and would like to add additional attributes to end points (that I initially intend to use for documentation purposes and later on for automation).
I do for instance have one (or possible multiple) "native" endpoint that the service is deployed with in container(s) and in addition to them several "virtualized" endpoints for instance in other network segments (WAN, DMZ...) created by XML gateways and "wired to" the native endpoint(s).
To support this I would like attributes that allow me to specify things like network segment and what "native endpoint(s)" that a "virtual endpoint" is "wired to" etc.
What part of the documentation covers this? Do anybody have some XML snippet that shows how to do it?
I would later like to try adding automation that pushes information to the right Gateway to create the virtual endpoints (perhaps tied to a special like cycle stage transition)... but that is a later challenge...
Endpoints are managed by a handler (org.wso2.carbon.registry.extensions.handlers.EndpointMediaTypeHandler). If you want to add custom attributes, you will have to extend this with your own.
Thanks,
Senaka.
Related
This conceptual question has crept into my mind after becoming more familiar with AWS. In general, I’m curious if there is a best-practice and/or convention as to when an API provider should group endpoints into a new, separate API (vs. lumping the endpoints into an existing API).
To illustrate, let’s say a Service creates digital wallet coupons on behalf of Manufacturers, to be redeemed by Consumers at a bunch of Mom & pop stores — some of the activities the Service might engage in include:
Receiving data from the Manufacturers (in order to build the digital coupons)
Providing a mechanism for Consumers to find and download coupons
Providing a way for the Mom & pop stores’ payment terminals to validate the coupons
And, oh by the way, the Service might also be required to ...
Implement a variety of endpoints, based on technologies involved (e.g., PassKit with Apple Wallet)
So?
With AWS, it’s easy to modularize one’s backend (e.g., have an RDS instance for the database, run a few lambda functions for microservices, etc.) and load balance it all. API Gateway adds to this in that each endpoint can point to different things (lambda functions, EC2 instances via HTTP proxy, etc.).
Consequently, one approach might be to define one API in AWS API Gateway and have all the endpoints underneath it:
API: “Master”
/coupon
POST = create a new one (for Manufacturers)
PUT = update an existing one (for Manufacturers)
GET = retrieve one (for Consumers)
/coupon/validate
POST = verify it’s still valid (Mom & Pop store use-case)
/apple-wallet
/{version}
/passes
... per documentation
/devices
... per documentation
But would it make more sense for the Service to shave off the /apple-wallet endpoint and create an entirely new, separate API?
Alternatively, if the Service was going to publish documentation for public developers to use, would it make sense to move the Manufacturer-relevant endpoints into a separate API altogether?
Since AWS makes the effort of splitting endpoints so simple via API Gateway, are there any standard practices for when you should (or should not)?
Thank you for any insights / opinions!
My two cents. Think about your end-user for your APIs. You will have different developer end-users for each API set.
Your ideal situation will have each developer end-user only seeing the APIs that are relevant to them. So you should split your APIs into different Gateways according to the end-users
In the theoretical situation you describe:
Create an API for Manufacturers so they can integrate with you to create coupons. If you do the integration internally it will be the corporate sales and presales people who talk to the manufacturers
The users for the Service and End User coupons might end up being the
same app developers that create an interface for both stores and
users. So create a coupon API for them
Separating both should also give you security benefits as you will protect the knowledge of your Manufacturer API from the users who might try to hack it
I am using Serverless and have a service with two functions.
I have setup API Keys to restrict access to the service.
One function does a basic task
The 2nd function is activated at the end of the 1st function to return a more thorough result.
I would like all API Keys be to able to access the 1st function but only some API Keys to access the 2nd function kind of like a premium feature that is activated for some users.
The only solution I can think of that works is having two separate services but this seems like a waste of resources as I have to request one API from the other. Is there a better way to do this?
You can see the usage plans associated with an API key and act on that information, see:
https://docs.aws.amazon.com/apigateway/api-reference/link-relation/usageplan-by-id/
https://docs.aws.amazon.com/apigateway/api-reference/link-relation/apikey-usageplans
So instead of requiring a mere presence of an API key, you can inspect some properties associated with it and decide to either allow or disallow the usage of your function based on that, but you will have to implement that logic inside of a function for the biggest flexibility.
For more info see:
https://docs.aws.amazon.com/apigateway/api-reference/resource/api-key/
especially links pointing to info on plans and marketplace.
I am using WSO2 APIM 1.10.0 on a single server deployment and would like to move to a clustering one. Looking at this documentation I could found a lot of information, howevre something is boring me; do I really have to always do all of it?
I mean, I don't want to split all my workers in multiple instances, all I want is configure two full setup configurations (key manager + publisher + store + gateway), each one on its own host and make sure I can put a load balance in front of it.
Thre requiremenst are simple: I would like to share the load on both of them, and guarantee a better availability in case of one of the hosts goes down. Is it a MUST break down the whole installation on both nodes so I have to start each component independently with offset ports configured?
I coud see that on version 2.0.0 a lot have been simplified, any way to reach the same on 1.10.0 one?
Regards
Splitting into profiles is not mandatory. This is designed in this way to scale API Manager based on the TPS. If you have a low TPS count and prefer to have 2 node HA setup, you can do the following.
Cluster the two nodes using wka, aws, etc.
Use dep-sync to share API artifacts between two nodes.
Use one node as the Publisher. You need to handle the publisher node traffic using single node. This is to avoid getting SVN conflicts.
You can serve API requests from both nodes.
You do not want to always use the same deployment pattern mentioned in the docuemtnation that you have pointed there. There are various Other deployment patterns that you can use according to the scalability and the requirement of yours.
Please refer the following documentation [1] for different deployment patterns you can use for WSO2 API Manager and [2] for more information on worker Manager separation and Load balancing.
[1] https://docs.wso2.com/display/CLUSTER44x/API+Manager+Deployment+Patterns
[2] https://docs.wso2.com/display/CLUSTER44x/Separating+the+Worker+and+Manager+Nodes
I want to deploy only one carbon product (one JVM) containing the ESB component and the api gateway component.
Is it possible to build this kind of application ? Is there any reference documentation explaining how to do that ?
Thanks.
Every Carbon-based product comprise of a set of installable/uninstallable features. You can get an ESB pack and install API manager features on it (can do this via the management console UI). However you won't be able to put together mismatching versions of the features (features released for different carbon platform versions/components) so this is subject to availability of matching components. This documentation on feature management will give you some insights on how to do it. (There can be cases where components may be in total conflict though)
But if your requirement is just running two products on the same machine, you can consider running them with port offsets, which is easier.
I am evaluating WSO2 G-REG and would like to create some new asset types like Integration (similar to a service but with other attributes and with other life-cycle stages) and Application (basically a consumer of service(s) that itself does not expose any endpoints and that once again has its own set of life cycle stages).
I have seen some examples about how to add attributes to existing asset types (and to modify there life cycle stages) but so far not figured out how to create new ones (from the product feature list I get the impression it should be possible)...
Pointers to documentation or even better some examples or XML snippets are warmly appreciated!
You can find some information in here.
Thanks,
Senaka.