Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What if a block doesn't have any output? #7

Open
matthewhudson opened this issue Dec 3, 2012 · 4 comments
Open

What if a block doesn't have any output? #7

matthewhudson opened this issue Dec 3, 2012 · 4 comments

Comments

@matthewhudson
Copy link
Member

For example, the send email block doesn't have any output. I vote we send a 2xx and an empty response body.

@progrium
Copy link
Member

progrium commented Dec 3, 2012

{ "result": null, "error": null}

Maybe?

On Sun, Dec 2, 2012 at 6:56 PM, Matthew Hudson [email protected]:

For example, the send email block doesn't have any output. I vote we send
a 2xx and an empty response body.


Reply to this email directly or view it on GitHubhttps://github.com//issues/7.

Jeff Lindsay
http://progrium.com

@tlrobinson
Copy link
Member

Probably best to return an empty object for consistency and to signal "success". It functions just like other blocks, it just happens to have no outputs.

I was also considering whether the email block should have an output, maybe called "success", but I guess that's implicit in the block returning the empty object. Maybe some pipeline variants could have success/error outputs that you could pipe to other blocks.

Also I'd leave the error property off unless there's actually an error.

@matthewhudson
Copy link
Member Author

Wouldn't success be implied by the Status Code? Although, if we're moving
the direction of JSONRPC and multi transport, then HTTP Status Codes are
off the table to signal success or failure.

Thanks,
Matthew Hudson

@tlrobinson
Copy link
Member

True, the status code should imply success.

Since it's called WebPipes I don't think we should avoid using HTTP features for the sake of other transports. We can always just tack on status codes and headers to the request/response objects when using other transports, etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants