Hacker News new | ask | show | jobs
by robotmay 3235 days ago
I actually use the 418 code in a simple API we use for IOT devices. I wrote a small program that runs on Raspberry Pis that checks a HTTP endpoint and turns power on and off to a room depending on whether the room is booked out. I wanted a status code on the API that could only possibly be generated on purpose, so if it receives a 418 response it knows to turn off the power; any other response, failure etc turns the power on (so we don't have a room out of use if it breaks).

Also it's fun :)

2 comments

I was hoping for a minute that the IOT device was a connected teapot...
I solved this with a WeMo plug, which gives me an app and alexa control. Used for electric hair iron of wife, and coffee pot as backup plan with timeout setting, and also saving us driving back home for the "did you unplug the iron" moments.

Both appliances actually have their own auto-off, but I like redundancy.

But does it respond to HTCPCP?
Unfortunately my flat is too small for me to justify a networked kettle...yet ;)
Why check for a special status code, rather than a specific response body, such as a JSON document confirming no use?
> a JSON document confirming no use

That would be the better design. No need to overload an HTTP status code meant only to indicate transport status.

Honestly the main reason it works like this is that it was my first foray into Rust, and I found JSON parsing a bit of a pain, whereas matching status codes was very simple. If we expand it to return different options in the future then I'll probably rework it.
Interesting, if you happen to have some time, I'd love to hear about why parsing JSON was a pain.
Laziness :D

I think I was having trouble with string lifecycles due to how I was doing something, and at the time I didn't understand them (I'm still not super sharp on it if I'm honest) and just opted to take an easy way out. Lifecycle notation might be the one bit of Rust I find ugly, actually.

I should really revisit this little program at some point, but it's so stupidly simple and works so reliably that I haven't had the inclination to yet.

Gotcha!

FWIW, serde_json makes it very easy; if you were doing it yourself, I can see how it'd be harder :)

The second edition of the book's ownership and borrowing chapters go into String vs &str in great detail, if you want to become super sharp :)

(and yeah, we agree that the lifetime annotation isn't very nice looking, but every alternative we tried looked worse.)