Open lrita opened 8 years ago
Restful style api sounds nice at first glance, in fact it is hard to tell that restful api is better. Anyway, the most important factor to impact what kind of style we use is easy to use, simple to understand.
Our future http api is going to be like:
curl -X GET "https://$ip:$port/$queue" // get a message
curl -X POST -d "msg=hello world!" "https://$ip:$port/$queue" // post a message
where $ip, $port $queue should replace with actual values.
Maybe like this?
Create queue:
PUT /queues/$queueName HTTP/1.1
{
"partitions":16,
"replications":2
}
Delete queue:
DELETE /queues/$queueName HTTP/1.1
Update queue:
PUT /queues/$queueName?override=true HTTP/1.1
{
"partitions":16,
"replications":2
}
List queue:
GET /queues HTTP/1.1
GET /queues?queue=$queueName HTTP/1.1
Add group:
PUT /queues/$queueName/$groupName HTTP/1.1
{
"read":true,
"write":true,
"url":"xxx",
"ack": false,
"ips":"xxx,xxx"
}
Delete group:
DELETE /queues/$queueName/$groupName HTTP/1.1
Update group:
PUT /queues/$queueName/$groupName?override=true HTTP/1.1
{
"read":true,
"write":true,
"url":"xxx",
"ips":"xxx,xxx"
}
List group:
GET /queues?group=$groupName HTTP/1.1
Send message:
POST /msg/$queueName/$groupName HTTP/1.1
{
"type":"message|ack",
"ack":"[message ID]",
"message":"[base64encode data]"
}
Receive message:
GET /msg/$queueName/$groupName HTTP/1.1
GET /msg/$queueName/$groupName?waitseconds=10 HTTP/1.1
{
"ID":"[message ID]",
"message:":"[base64encode data]"
}
Monitor:
GET /monitor HTTP/1.1
GET /monitor/$queueName HTTP/1.1
GET /monitor/$queueName/$groupName HTTP/1.1
the terms of "queue" and "group" make sense within pub/sub context. actually, in most cases, the consumer cannot tell and will be confused by the differences of "queue" and "group". So, it seems easy to understand, reduct the two term to only one: "queue".
HTTP API need change to Restful style? If do this, maybe graceful.