The document from which you quote is a draft for "A Convention for HTTP Access to JSON Resources" which, according to appendix A, does not itself describe a RESTful interface. I'm not sure the draft is, in fact, "useful to have a nice standar REST API."
As far as I can tell, the HornetQ REST interface adheres to the common REST conventions. It's also worth noting that there isn't a REST specification per se so how RESTful an interface is can be subject to debate. That said, based on what you've presented I can't find a reason to implement any changes.
my only observation is the use of /create as some kind of RPC method call when POST and PUT already mean create
you can see it in the HTTP method definition http://www.w3.org/Protocols/rfc2616/rfc2616-sec9
The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line.
my interpretation of "as a new subordinate of the resource identified by the Request-URI" is that it lets the server decide the id for ir and return it in some way (maybe a link header)
The PUT method requests that the enclosed entity be stored under the supplied Request-URI
in this case the user provides the resource URI where the resource can later be found (in this case provides de id)
that means that when you create a resource and supply the id for it it should be
and creating it without the id should be
just that, I wasn't implying all the API is not REST, just that the create method/URI may be improved.