Tesla's "REST" API, and honk_horn end-point - web-services

Question

GET /vehicles/{id}/command/honk_horn
As seen in this post:
https://news.ycombinator.com/item?id=7961944
There is a debate about what verb should be used for the honk_horn resource. Answers include:
GET, because you're not changing the resource state
POST and not PUT because honking twice is not idempotent
PUT, because honking twice might be considered idempotent :S
Perhaps the root of the problem here is that honk_horn is really an action and not a resource, and so in this particular case how should one define as API to issue a command while remaining RESTful?

Answer 1

Perhaps the root of the problem here is that honk_horn is really an action and not a resource
Yes, I would say so, that's the core of the problem. A resource oriented and hypermedia based approach could look like this (using Mason https://github.com/JornWildt/Mason to describe actions):
GET /vehicles/12345/horn => return status of horn (a resource in itself)
{
volume: 5,
numberOfHonks: 1025,
#actions:
{
"honk":
{
type: "void",
href: "/vehicles/12345/horn/honks",
method: "POST",
title: "POST here to honk horn once"
}
}
}
GET /vehicles/12345/horn/honks => return previous honks (a resource in itself)
{
numberOfHonks: 1025,
honks:
[
{ date: "2010-12-24T10:24:12" },
{ date: "2010-12-24T10:24:14" },
{ date: "2010-12-24T10:24:20" },
... 1022 other honks (or perhaps only latest top 100 honks)
]
}
POST /vehicles/12345/horn/honks => Add one honk (empty payload - or maybe even include volume and pitch ...)
Fun exercise :-)