Turning Services into APIs
Turning Services into APIs
Learn all about turning services into APIs: the differences in services and APIs, and how to accomplish this feat with Mulesoft.
Join the DZone community and get the full member experience.Join For Free
It is very common these days for organizations to have developed a large set of internal services for which there is a desire to publish these as APIs.
Typically the key differences between a service and an API in this context lies in:
Security (Key and user management)
Management (SLA's, throttling, quota's)
Reporting and monitoring
Design (internal system accessibility vs consumer first design)
As an organization takes its first steps into APIs - the use of API gateways as a proxy represents a low friction progression which addresses the first 3 of the primary differences. The fourth typically requires an increased organisational capability anyway, and in this manner, they can assist as an educational exercise towards this goal.
Mulesoft's Anypoint Platform represents one of the tools that can be used in this area - which for the remainder of this article I will show the ease of converting an existing HTTP-based service into a consumable API.
Starting by signing into https://anypoint.mulesoft.com (I'm assuming you're able to get through the registration process yourself - and configure the actual gateway instance you'll be using) - you'll be confronted by the Home screen. We're interested in the 'APIs' link in the top right:
From here you're going to be presented with a list of your existing API definitions (which is going to be a pretty short list if you've just signed up):
The big green Add new API button is where you want to go now:
Give your proxy a name and version and you're now at the heart of the current API definition:
The key thing we need to do here is "Configure endpoint" - on the right middle.
As you start on the journey - the simplest form of proxy to deploy is an "HTTP URL" proxy. Basically, this acts the same as a proxy for a website - every request to the gateway will be passed on to the backend service without any direct transformations or routing being applied. More importantly, the gateway itself won't be looking to enforce the contract/definition of the API. A RAML proxy is much more powerful in this respect - but involves the extra steps of understanding and writing the RAML which can be a daunting prospect when just starting.
The implementation URI is the fully qualified URL of the service you are wrapping - which must be callable from the Gateway instance - but does not need to be callable (or even referenceable) by the end API client.
The path is the other important setting here - if you're hosting more than one API on your Gateway (and there're not many instances where this is likely to be a good idea) - this is how you're going to differentiate between your instances.
Use "Save and Deploy" or "Save" and then use the "Deploy proxy" link:
Pick the gateway instance(s) you want to host your endpoint - and "Deploy." A few seconds later and your Service is ready for use:
However - at this point; you've still really got a Service which just happens to be externalized/externalizable. You need to go to the "Policies" (middle bottom of screen) in order to evolve this towards API status:
The beauty of this is that you can apply the majority of these policies on the fly - just by clicking "Apply". In some cases - like CORS - this will give you a modal in which you can configure the policy specific settings, and then you're done. This is especially useful in an environment where your existing services are implemented in a variety of different languages, frameworks or even COTS. You can now apply and manage uniform security and access control (including API Keys etc) all from the same place, and just as importantly monitor usage!
The link at the top right "Analytics" will give you across API visibility on a request by request basis - enabling that critical aspect of API lifecycle management to occur.
Please feel free to comment - in particular with respect to areas of this topic in which you would most like to see expansion in further posts.
Opinions expressed by DZone contributors are their own.