• If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • You already know Dokkio is an AI-powered assistant to organize & manage your digital files & messages. Very soon, Dokkio will support Outlook as well as One Drive. Check it out today!


RESTful WebFlow

This version was saved 14 years, 8 months ago View current version     Page history
Saved by nathandw
on October 9, 2009 at 3:03:50 pm



What is WebFlow?


WebFlow describes the interaction of WebHooks, WebScripts, and WebServices; WebFlow is workflow for the web. RESTful WebFlow is intended to be used by RESTful WebHooks and RESTful WebServices. The primary implication of this is that RESTful WebFlow operates as a state machine rather than a sequential flow. This requirement is based on the fact that REST is stateless. This is necissary in order to support a RESTful and therfore stateless web. If I post a resource to a WebService (WF Activity) I should not expect a response other than HTTP Success/Error codes; the result of the activity is broadcast via WebHooks not returned from the service invokation. WebFlow is an attempt to identify service interaction points and recommend best practices that will aid in the evolution of a programable web.


WebFlow should seek to define standards of messaging for common activities such as approval. WebFlow should also attempt to tackle enterprise level concerns such as data security. A simple WebFlow that touches on these issues follows:


Lets say I have subscribed to a WebHook from my cable company that broadcasts my bill when it is ready. I would like to to be notified via SMS and be able to reply with "Yes" or "No" indicating whether I want to pay the bill right now. The text message will also contain my current checking account balance so I know if I have enough to pay the bill. If I approve the payment I want a WebScript to contact my bank and schedule the payment. 


If WebHooks is to evolve beyond cutsie tasks like reposting tweets it will need to support these kinds of scenarios. What is to stop me from posting my account balance or other sensitive info to Twitter? Common sense is the obvious answer but there is a good chance I will be using a WebScript developed by another person, just as people use malicious plugins for FaceBook I may be using a malicious WebScript. However, unlike FaceBook, WebScripts may be used to move around this kind of sensative data? The simplest solution is for my cable company and bank to to talk directly and only let me in on the approval. Of course this kind of defeats the purpose of WebHooks/WebFlow. What if I want to pay using PayPal? The other option is to build some sort of security into WorkFlow, for example, certain secure activities will only accept/publish data to be consumed by other secure activities and will not accept certain data being published to non secure locations. How or if this can be done should be determined by the WorkFlow initiative.

Comments (0)

You don't have permission to comment on this page.