Creating APIs with SnapLogic Pipelines and Ultra Tasks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-06-2017 03:37 AM
Overview
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”
Designing the Pipeline
Ultra Tasks deliver the components of the HTTP request message to its associated Pipeline as fields in the JSON document:
- content: The request body for POST or PUT requests
- headers: For example, the ‘User-Agent’ HTTP header can be referenced in the input document as $[‘user-agent’]
- uri: The original URI of the request.
- method: The HTTP request method.
- query: The parsed version of the query string. The value of this field will be an object whose fields correspond to query string parameters and a list of all the values for that parameter. For example, the following query string:
foo=bar&foo=baz&one=1
Will result in a query object that looks like: { "foo" : ["bar", "baz"], "one": ["1"] }
- task_name: The name of the Ultra task.
- path_info: The part of the path after the Ultra task URL.
- server_ip: The IP address of the feed-master that received the request.
- server_port: The TCP port of the feed-master that received the request.
- client_ip: The IP address of the client that sent the request.
- client_port: The TCP port of the client that sent the request.
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:
Additional Reference
https://en.wikipedia.org/wiki/Representational_state_transfer
http://doc.snaplogic.com/ultra-tasks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-12-2018 01:35 PM
The documentation pages for the Snaps have sample pipelines, see JWT Generate and JWT Validate
