Simple http endpoints

[viktorerlingsson]

We're exploring a small HTTP API for publishing to and consuming from a queue without an AMQP/MQTT client. See PoC in #1880

The thought is to add something that would be very simple to use and doesn't require AMQP knowledge.
But the exact features depends a lot on how this would actually be used. So before we commit to anything, we'd like some input.

Please leave a comment if you have a real or planned use case for this, or your take on any of the topics below.

Some things we're looking for input on are for example:

• What would you use this for?
  IoT/embedded devices, webhook receivers, serverless, etc
• Should queues auto declare on first publish?
  Yes, no, configurable?
• ack / no_ack
  Should messages be auto acked when GETing? Is that too much of a risk if something goes wrong on the client side?
• Pull/Push
  Does it make sense to just get data? Should there be a "consume" alternative?
• Queue metadata
  No way of knowing what the queue setup is or what the queue contains, should we provide metadata as HTTP headers?
• Message metadata
  Same as for queues, should we provide message metadata as HTTP headers?
• Naming
  What should the endpoints be called? What path?

[ch1c0t]

What would you use this for?

For inter-process communication.

amqp-client.cr works via Unix sockets, but most AMQP clients work only via TCP. HTTP endpoints could enable the use of other languages, besides Crystal, via Unix sockets.

It is often desirable, when there is a good library for Python, to have a Python service running in the background, to not have to incur its startup cost every time it is needed. Since CLIs implemented with Crystal start immediately(without humanly perceptible delay), it is tempting to implement CLIs in Crystal, and make them communicate with such Python services(preloaded in the background).

Thanks.