If you have already watched the “Using apiman” video, then you know how to provide and consume services through plans. However, if you aren’t interested in the power (but added complexity) of service plans and contracts, you may want to know about public services.
A public service is simply a service that may be invoked by any client, without first needing a contract (and thus a valid API Key).
There are distinct advantages and disadvantages to using public services in apiman. The advantages of public services include:
They are simpler to set up and use.
They do not require Plans or Applications to be created.
Policies can still be configured directly on the Service - so there is no loss of functionality.
However, there is a tradeoff for that simplicity. Specifically,
Because Plans aren’t used, the Service cannot offer multiple SLAs,
and all Services must be configured separately.
In addition, there is no way to track or control the clients that invoke the Service (at least not in the same way as when using Applications and Contracts).
Let’s go ahead and see how a public service is created and used.
First, we’ll log into the API Manager and create a new Organization to hold our public service.
The Service is created in the same way as usual, giving it a name, description, and initial version number. Once the service is created, we still have to configure the Implementation Endpoint. For this demo we’ll just use our standard echo service.
This next part is what’s different - instead of configuring a set of Plans, we’ll simply make the Service public by clicking the available checkbox on the Plans tab.
As always, we can configure any number of policies on the service, all of which will be applied to any request made to the Service. For this demo, I’ll just add a simple Rate Limiting policy to show everything is working. I’ll set the values quite low to make it easy to violate.
After all our service configuration is done, we can simply Publish the Service to the Gateway as per normal.
Now we need to know the URL of the managed service so that our client can invoke it. That information is available on the Endpoint tab. We can simply copy and paste that endpoint into our test client to make sure it works.
As you can see, sending requests to the endpoint we copied works like a charm. And of course if we try to send too many requests in a short period of time, the rate limiting policy will kick in and fail the extra requests.
It’s certainly a lot easier to get started with public Services, but make sure you understand the tradeoffs. You won’t be able to see a list of your consumers, and you won’t be able to offer your service through different plans.
Thanks for taking the time to watch this video. You can find other awesome apiman videos on the apiman project web site.