• Register

TIBCO Cloud Mashery API Developer Blog

Wild-card parameters in end-points

 

We listened to your feedback and are excited to let you know about a new feature addition – wild-card parameters are now allowed in end-point definitions! This will allow you to simplify your setup a great deal and yet not lose the level of visibility you require into method-level API usage.

The feature is easier explained with a specific example. Let’s say you had to setup patient related information as an end-point in the system, but the end-point needs to accept a variable patient ID value in the request path. You can simply use a meaningful parameter to denote patient ID in the request path such as {patientID}. You could also use the same correspondingly in the end-point path as shown below:

 

Also if you need fine-grained reporting and analytics on the usage pattern by the {patientID} wild-card parameter, you can configure appropriately in your methods configuration as shown below:

For the above example, if a request came in as say api.acmehealth.com/v1/patients/945673, it will be matched to this end-point in the system. The request will be routed to backendservice.acmehealth.com/internal/patients/945673/data. In addition in your method level reports, because of your methods configuration in API settings, you can see usage for v1 patients 945673

In essence with this feature, you no longer have to setup either multiple end-point paths for different patient IDs in the above example or take a coarse-grained approach to setting up end-points such as v1/patients/. The former was cumbersome and sometimes near impossible if you had multiple combination of such IDs in your request path. The latter will not necessarily allow you to get the right type of fine-grained reporting on your API usage. Wild-card parameters in end-point paths allow you the right type of flexibility with your end-point setup