spec
spec copied to clipboard
webpipes
Webpipes is a work-in-progress proposal for linking together web services. Essentially, you can think of webpipes as tiny web services modeled after the UNIX philosophy: small utilities that do one th...
I've added some [JSON Schemas](https://github.com/webpipes/spec/tree/master/schemas) describing the block definition, inputs, and outputs. I used the file extension ".schema.json" because, as far I can tell, there is no standard file extension...
Based on the work of @progrium [HTTP Subscriptions](https://github.com/progrium/http-subscriptions)
Use three simple, common response codes indicating (1) success, (2) failure due to client-side problem, (3) failure due to server-side problem: - 200 - OK - 400 - Bad Request...
This will encourage libraries to conform to standard guidelines for behavior and method naming. The [sixpack](https://github.com/seatgeek/sixpack/blob/master/CLIENTSPEC.md) A/B testing framework does this well.
There are some arguments against using OPTIONS (caching, poor support in servers/clients): http://www.mnot.net/blog/2012/10/29/NO_OPTIONS http://www.mnot.net/blog/2005/04/03/options But I don't know, I still like the idea of using OPTIONS.
I think Matt mentioned this early on: what we have is fairly close to JSON-RPC. Maybe it's worth making it compatible? JSON-RPC 1.0 uses an array of arguments, but 2.0...
For example, the send email block doesn't have any output. I vote we send a 2xx and an empty response body.
In the `formatter` block it looks like we assume there is a "*" property on the input object, which is itself an object containing arbitrary keys. I assumed "_" would...
It would be nice if blocks could output an error message. Maybe send a 4xx/5xx status code along with an object that looks something like this: ``` javascript { message:...