"200" makes sense. See wikipedia article on /dev/null[0]: "discards all data written to it but reports that the write operation succeeded."

[0] - http://en.wikipedia.org/wiki//dev/null

wouldn't 202 be better?

204 No Content would.

202 assumes a possibility of further processing, but /dev/null can offer none.

True, but that still mirrors the successful wrote responses in the UNIX file system, right?

Shouldn't it return the status code "410 Gone"?

I think it should be "204 No Content".

200 for a POST, 204 for a GET.

I second this one! makes more sense than plain 200.

I can't believe you guys are debating the correct HTTP return code for a joke service? Besides, it's obviously 200.

These provide great opportunities for better understanding return codes.

Besides, for POST it is obviously 202 ACCEPTED

Does it discard data in a manner compliant with FIPS 140-2? Or NIST SP800-88?

Wait... is it a joke?

I hope not, I've been depending on this service for a while. I have it integrated via FUSE on my prod servers.

We did have some problems of blocking on large files, which is less than ideal for a /dev/null service.

After dealing with their customer support (which has been super helpful), we are looking to move to a named pipe / FIFO.. Which will non-block and cache lolcally, with a watcher service to push it to their site.

Happy Customer, A+++, would recommend.

Well with the planned dev/random support, this is going to kick ass.