Item — HN Reader

Using GET to trigger horn honking... Not sure I'd consider that good REST practices.

(At least honking the horn doesn't incur permanent state change; unlocking the doors is obviously not safe.)

Edit: idempotency vs safety... I knew I was being stupid.

6 comments

I have visions of a rube-goldberg style contraption, starting with the car horn activating, scaring a flock of pigeons, knocking over a set of bowling pins, bumping into a lit candle and tipping it under a rope, burning through and releasing a piano on some poor sap's head. No side effects, indeed :)

Or, on the other hand, it's a zen koan. If a car honks in a parking garage and no-one is there to hear it, has it even made a sound?

The 'unlock' operation, at least on most central locking systems I've used, is the perfect example of an idempotent unary operation.

It doesn't matter how many times you apply the 'unlock' operation, it has the same effect as applying it once[1]. However, the 'unlock' operation is not safe[2].

[1]: http://en.wikipedia.org/wiki/Idempotence

[2]: http://www.packetizer.com/ws/rest.html

Unlocking doors absolutely is idempotent. What different state would you see if you issue Unlock once or a thousand times?

Solenoid melted?

Thinking like an embedded systems engineer (I am) instead of a mathematician (I'm not), I would have a sensor to know the state of the lock and only whack the unlock solenoid if the lock has been discovered to be closed.

Always treat mechanical devices in a non-deterministic fashion.

As a software developer I'd always try to unlock it. The user probably has a reason for pressing the button. Maybe your "is the door locked" sensor is broken? If you're afraid of overheating it wait a bit after the second try before enabling it again.

You might be surprised by the semantics assigned to double clicking the button by some manufacturers. On some BMWs (mine included) locking it twice DISABLES the alarm. It's intended for ferries / low-loader recovery etc. but if you don't know it...

The lock button on a BMW is completely driven through the CPU. When you lock the car with the remote, the lock buttons inside the car AND THE DOOR HANDLES do nothing. Anti-theft measure I suppose.

Salesmen have to remind every new customer about this, since sooner or later someone locks themself or someone else in the car and the remote has walked away...

VWs can do a thing where the windows open if you hold the lock key down - fortunately this can be turned off in the cars configuration settings for people who live in rainy countries!

Just to be precise, the windows open when holding the unlock button, and close when holding the lock button.

The user manually requesting an unlock is one thing. He's the software running the lock. I'm talking more about an automatic unlock request from high-level software control.

There are techniques to monitor the health of the switch and know when the sensor is failing/has failed. THEN you can whack the solenoid to your heart's content if you believe the sensor is damaged. But if you have a working sensor, there's no need to overstress the solenoid and mechanical linkage.

Funny that you say this, my Honda Civic always attempts to unlock regardless of lock state. I guess they don't really trust the lock sensor.

I'm not saying this is how every car is or should be designed, especially a Civic. You're also in the vicinity of the car - either you're sitting inside it or you're using the keyfob within visual distance.

But if you're locking/unlocking your car over the internet with this funky API and want to be sure it's locked, how do you do it? You don't hit the solenoid 20 times and say "well, good enough".

> non-deterministic fashion.

Wait, perhaps I am understanding it wrong, but if I were to consider a lock sensor as non-deterministic, wouldn't that imply that I always have to send the unlock signal, regardless of lock state, because you don't trust the sensor?

You consider the mechanical state of the lock mechanism to be non-deterministic. The sensor has no state, it's an observer.

You do not trust that because your boolean in RAM says "locked" that the door is locked.

Now whether you trust the sensor to be functional or not is another story.

Tip - the human in or near the car reacting to the first opening...

Unlocking door is idempotent, but it is not safe (has side effect), and thus, according to the HTTP standard, GET should not be used for it.

Yeah, I considered not carrying the wireless-entry key for my car, because if I lost that key, it would be easy for a thief to walk through the parking lot, pushing the button until they found my car.

Ultimately, I decided that I'm unlikely to lose the key. But I don't like the idea that someone could still scan the parking lot, unlocking cars by radio.

Opening up more data/control wirelessly isn't necessarily a good thing. You CERTAINLY don't want someone to be able to make your car segfault while you're driving down the highway.

>You CERTAINLY don't want someone to be able to make your car segfault while you're driving down the highway.

That could make for a great scene in some futuristic hacker movie.

On a more serious note, there are many possible solutions to the problem of losing a wireless car entry key. Off the top of my head:

1) Have the user tap out a simple rhythm with the button to unlock the car. Downsides: kind of involved and the rhythm would have to be long to be secure.

2) Put a fingerprint scanner on the key. The one in my laptop is a tiny self-contained module, so I expect it to be possible to fit one inside a wireless car key. Downsides: the scanner can break; can't use in gloves.

3) Have the cars mesh network to detect the "trawling for the right car with a key" behavior. Downsides: complexity; the thief could exploit this to lock you out of your own car.

4) Make the key a wristwatch or a wristband. I think this is the best cheap solution. Downsides: might disagree with your fashion sense.

What's wrong with putting the second auth method (fingerprint, passcode, whatever) on the car itself? Likely much more durable and keeps the key itself simple.

"Person of Interest" had it...

Keyless entry has been around for a long time and I have not heard of this scenario actually occurring (no doubt it has, but it's certainly not common enough to worry about).

Just think of what a single index crawler could do to this car!