If it gets ugly for the consumer you might wanna have a look at the facade design pattern:
http://en.wikipedia.org/wiki/Facade_pattern http://en.wikipedia.org/wiki/Software_design_pattern You can hide all complexity behind the facade through an easy to use API. If you have a better command line version, or built your own implementation, you can easily link your facade to the new version. Am Freitag, 14. Juni 2013 12:51:31 UTC+2 schrieb ryandesign: > > Thanks for your responses! Mine are below. > > > On Jun 13, 2013, at 23:38, Aria Stewart wrote: > > > On Fri, Jun 14, 2013 at 09:09:33AM +0530, Hage Yaapa wrote: > > > >> What you are asking for is not recommended. Request should either be a > >> success or a failure. > > > > I concur here. > > > > Try to avoid 'warning' cases -- reduce the interface until there's only > cases > > you're willing to handle separated from cases you're not. It's that much > more > > surface area for the API, and that much harder to plumb together > something that > > interprets it well. > > > > Try to take advantage of idempotency -- accept a repeated action as if > it's the > > first time. It makes building a robust system much easier ("I'm not sure > that > > worked. Send it again!") > > > > Then when you have real errors, throw the best status code and most > useful > > diagnostics -- preferably in a consistent, easy to parse format -- and > call it > > a day. > > > > If you need an "I know what I'm doing" flag, add it to a repeated > request. > > > > TL;DR. There are no non-fatal errors, just retriable ones and > non-retriable. > > > Part of the problem is that I am trying to create a web service around an > existing command line program that's not mine. I can't really control its > behavior. I can just give it input, and deal with its output. For various > inputs, this program's behavior is: > > * output on stdout and zero exit code; I'll send a 200 OK and pipe the > program's stdout to the response > * error messages on stderr and non-zero exit code; I plan to send 400 Bad > Request to the browser with the text of the error messages > * crash and non-zero exit code; 500 Internal Server Error > * hang; I plan to set a maximum process runtime and return a 500 Internal > Server Error when it's exceeded > * output on stdout and zero exit code and error messages on stderr; this > is the case I am trying to figure out how best to handle > > In the last case, as I mentioned, there are some messages the user can't > do anything about (e.g. diagnostic messages about bugs in the program being > triggered by this particular input), and there are some the user might want > to know about (e.g. requested font not found, using fallback). > > For now, I'm thinking if the program produces output and a zero exit code, > I'll send it to the browser, and either just log stderr to the console, or > also try to send Warning headers as below. I can monitor what kinds of > warnings are getting logged, and decide on a case-by-case basis whether I > want to promote any of those warnings into fatal errors. > > > On Jun 13, 2013, at 23:55, Alex Kocharin wrote: > > > Use "Warning" HTTP header. See > http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html > > > > It's not a "custom http header", but a standard one. ;) > > Thanks, I wasn't aware of the Warning header. That's at least a > possibility. The spec says browsers "should" display these warnings to the > user but I'm not sure if any do or if I would want them to. > > > On Jun 14, 2013, at 01:20, Jörg Eschmann wrote: > > > I would say your problem lies in your architecture. > > > > If you have a clearly structured service, the json object would be > adequate. > > Generate the image and store it temporarly on your server. > > That is also good for caching, if users send the same request, you can > easily check if the image is already available. > > Then you send the link in the json response object and fetch the image > in a second request. > > To some extent, I'm trying to model my architecture on an existing one, > which uses the described method of describing the request completely in the > URL, and receiving the desired output in the http response. But, that > existing architecture is quite old, so there might be better solutions > today. > > I had thought about storing the image and redirecting. It complicates the > API for consumers. I was already planning on having an (nginx?) server in > front of node to do caching. > > > -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
