Why make URLs pretty?
Services registered in a Leap Feature are accessed by using a URL that is generated based on convention. The default URL is very clear for developers familiar with Leap, however, when it comes to branding a set of services as a product or integrating with external systems, the naming convention can seem verbose.
It is possible for features and services to be re-used in a different context, when this applies, addressing a service by another name may be appropriate. Assume we have a Feature such as the eWMS UI Feature; if it’s being used for building a non-WMS related UI, the name “ewms” (elastic wms) no longer applies. Instead, it’d be helpful to rebrand the service URL “ecomm/rest/ui/ewms/submitData” with another name like “/backend/sendData”.
Using pretty URL for Leap Services
Base Route
In the BaseRoute.xml we’ve added another endpoint that uses port 9070. Whenever we are receiving a request on this port we are assuming the URL is a “pretty URL”.
<serverName> : 9070/<prettyUrl>
localhost:9070/backend/sendData
Feature Service
Within the featureservice.xml file which every Feature must include, an optional attribute “prettyuri” has been added to the <GenericRestEndpoint> tag. By providing the prettyuri you are declaring a new alternative URL slug for that specific service.
<Service name="logIn" enabled='true' vendorName="wherewerks" Description="elasticwmsservice setup"> <GenericRestEndpoint httpMethod="GET" prettyuri="backend/login" urlMappingScheme="elasticwms/elasticwmsservice/logIn">elasticwmsservice-logIn-IR </GenericRestEndpoint> </Service>
In the above example, I’ve added “prettyuri=’backend/log'” which will make the service available via either URL:
- <server>:<port>/ecomm/elasticwms/elasticwmsservice/logIn
- <server>:9070/backend/login
How it works
When Leap is started, all of the prettyuri values are stored in the Leap Database using the table “prettyurlmapping”. This table includes the tenantId and siteId so that each mapping is made available on a per-tenant and per-site basis, allowing for multiple configurations after the fact. Additionally, the table includes the default URL for the service being called – internally, Leap relies on this to hit the proper feature/service.
As soon as the data is persisted, Leap fetches the pretty URL data from the table and caches it in Hazelcast. This allows for fast access to the data without using the JDBC connection, plus, it allows the data to be shared and resilient in the case multiple leap deployments are joined to a common Hazelcast cluster.
When an HTTP request reaches the baseroute as a pretty URL, leap will fetch the corresponding service URL based on the tenant, site, and prettyuri values. Once the original URI has been retrieved, leap continues as normal.