03-06-2017 03:37 AM
API (Application Program Interface) is an old concept repurposed to mean a modern web service based on the REST protocol and increasingly using the JSON data format. These modern APIs have become the franca lingua of the digital economy, by facilitating lightweight, performant communication between applications across an enterprise or across the internet.
Typically RESTful APIs perform operations on “resources” (Customers, Orders, People, etc). By convention, the type of operation is identified using the most common HTTP verbs such as POST (create), GET (read), PUT (update), DELETE
SnapLogic provides Ultra Tasks as the means by which a Pipeline can be exposed as a secure, high-availability, low-latency, sub-second request/response API.
For example, the following is a Pipeline that embodies a Customer API exposed using an Ultra Task:
Once the Ultra Task is enabled, the associated Pipeline stays resident in memory on the Snaplex node(s) it was configured to execute on. The number or Instances can be configured to accomodate the expected concurrent API request volume.
The API can then be called securely from an external application (Postman REST client in this case):
This is an example of an API GET (read) request for a specific Customer identified by the ID “1001”
Ultra Tasks deliver the components of the HTTP request message to its associated Pipeline as fields in the JSON document:
foo=bar&foo=baz&one=1
Will result in a query object that looks like: { "foo" : ["bar", "baz"], "one": ["1"] }
In the above Customer API example:
A Mapper Snap is used to parse the ID from the portion of the URL after the base path provided by the Ultra Task (demo-fm.snaplogic.io/api/1/rest/feed-master/queue/MyOrg/MyProjectSpace/API/Customers)… In this case “/1001”:
A Router Snap is used to conditionally direct execution to the appropriate subflows designed in accordance with the RESTful CRUD operations described above:
https://en.wikipedia.org/wiki/Representational_state_transfer
http://doc.snaplogic.com/ultra-tasks
11-13-2018 05:54 AM
Thanks for this post - it is helpful and aligns with one of the primary uses of SnapLogic for us at Davidson College. I have a few questions…
Is the Ultra task necessary to meet the general requirements of creating an API resource / endpoint or could we use a trigger task? In other words does the Ultra task only address the “low latency” characteristic?
One bearer token per task / endpoint is a bit cumbersome when considering building out an API-based architecture. For example, we want to provide access to multiple resources / endpoints for a single application or consumer via a single bearer token. Is there a tweak to your design pattern which would accommodate this?
Thanks again for this post. I hope to hear back!
~Nick
12-07-2018 01:13 PM
Ultra tasks allow for low latency, they also allow for data processing to continue when communication with the control plane is broken for some reason, allowing for higher availability.
Using JSON Web Tokens (through the use of JWT Snaps in the pipeline) allows for more control on the tokens. The tokens can be configured with an expiration time, there can be multiple tokens per task, a single token can be shared across tasks in a project or project space etc.
12-11-2018 07:48 PM
Thank you…
12-12-2018 01:15 PM
Do we have sample pipelines to demonstrate “2”