bip.io is an open source [RESTful](http://en.wikipedia.org/wiki/Representational_state_transfer)[JSON](http://www.json.org/) [API](http://en.wikipedia.org/wiki/Representational_state_transfer#RESTful_web_APIs).
It's an API orchestration and ephemeral endpoint server. Please see the Installation section of [the readme](https://github.com/bipio-server/bipio/blob/master/README.md) to get a basic server running. If you'd like to take a look at some of the things bip.io can do, browse the cookbook in the sidebar or [sign up to bipio](https://bip.io) explore what's been shared by the community.
It's an API orchestration and http endpoint server. Please see the Installation section of [the readme](https://github.com/bipio-server/bipio/blob/master/README.md) to get a basic server running. If you'd like to take a look at some of the things bip.io can do, browse the cookbook in the sidebar or [sign up to bipio](https://bip.io) explore what's been shared by the community.
This open source server API matches what you'll find on the hosted community platform and visual editing tools at https://bip.io.
This open source server API matches what you'll find on the hosted community platform.
Don't worry, you'll soon be on your way to creating useful bips!
...
...
@@ -35,15 +35,16 @@ There are many reasons to use an ephemeral graph system, here's some highlights
### So how does it work?
When you define a bip, you are defining the characteristics of a named graph. SMTP and HTTP bip payloads are normalized for each respective protocol, and trigger content is normalized from the channel that is invoked. SMTP/HTTP bips are 'on-demand' and they fire whenever a new message is received. Triggers are fired whenever the periodic scheduler requests it.
When you define a bip, you are defining the characteristics of a [directed graph](https://en.wikipedia.org/wiki/Directed_graph).
When a message is received or generated from a trigger, it enters the target bip's graph via the 'source' vertex/channel. Any exports are then normalized and sent across adjacent edges to the next-nearest vertex via RabbitMQ for consumption as a new import. The source message may be transformed in certain ways depending on your transform rules, and will continue to feed forward from 'source' until all vertices have been visited.
When a message is received from a web hook, incoming email or generated from a trigger, it appears on a bips graph from the 'source' node. The source data is then normalized into a JSON structure and 'exported' via RabbitMQ for consumption as 'imports' by adjacent nodes. This pipeline continues until all nodes have been visited.
As a message is pushed through a graph, it builds a stack of imports from prior visited channels which can be further transformed and imported. See the [bips section](https://github.com/bipio-server/bipio/wiki/Bips) for more info.
Prior to consumption, imports can be modified in different ways. These modifications are called 'transforms', or ['personalizations'](https://bip.uservoice.com/knowledgebase/articles/502740-personalizing-your-integrations) in the UI. As a message is pushed through a graph, an object is built containing exports from visited nodes which can be plucked out and re-assembled using [JSONPath](http://goessner.net/articles/JsonPath)
#### A note on files
Received or fetched files are not present as explicit imports/exports but rather appear to a hub when made available. Certain channels will operate with the assumption that these files are present (eg: dropbox.save_file)
Received or fetched files are not present as explicit imports/exports but rather appear on a graph as they become available. Certain actions will operate with the assumption that these files are present eg: Dropbox > Save File will only run when a file is present.
## API
The API is namespaced as RESTful resources, and RPC's with `/rest` and `/rpc` respectively. [JSONP](http://en.wikipedia.org/wiki/JSONP) is supported with a `callback=your_function` GET parameter.
