Skip to content
This repository has been archived by the owner on Jan 22, 2019. It is now read-only.

Support APIs which return links #39

Open
fgabolde opened this issue Sep 18, 2014 · 0 comments
Open

Support APIs which return links #39

fgabolde opened this issue Sep 18, 2014 · 0 comments

Comments

@fgabolde
Copy link

I'm using a RESTful API (documented here) for the OpenStack message queue service. I have a complete SPORE spec for it, it works well enough.

My issue is with several types of responses that contain links to other resources; for instance, a common workflow with this API is to "claim" several messages on a given message queue. The server then tags those messages internally with the claim ID so that no one else will be able to claim them and returns a response with the claim ID and the messages.

$client->claim_messages(queue_name => 'tomato', limit => 10);
> POST /v1/queues/tomato/claims?limit=10
> {"ttl":60, "grace":60}
< 201 Created
< Location: /v1/queues/tomato/claims/a28ee94e-6cb4-11e2-b4d5-7703267a7926
< [ { "href":"/v1/queues/tomato/messages/50b68a50d6f5b8c8a7c62b01?claim_id=a28ee94e-6cb4-11e2-b4d5-7703267a7926", "body": ... }, ... ]

Now my problem is that although I know in advance what type of resources the various links in the response point to, I cannot call the corresponding client methods with the correct parameters, e.g.

# how can I get the values for queue_name, claim_id and message_id ?
$client->release_claim(queue_name => 'tomato', claim_id => 'a28ee94e-6cb4-11e2-b4d5-7703267a7926');
$client->delete_message(queue_name => 'tomato', message_id => '50b68a50d6f5b8c8a7c62b01', claim_id => 'a28ee94e-6cb4-11e2-b4d5-7703267a7926');

I can sort of get the querystring parameters, but extracting route parameters is going to be much harder. Ideally I'd do something like

$client->call_url(method => 'DELETE', url => '/v1/queues/tomato/messages/50b68a50d6f5b8c8a7c62b01?claim_id=a28ee94e-6cb4-11e2-b4d5-7703267a7926');

I've tried poking around in the internals of Net::HTTP::Spore but I don't believe this is possible without some refactoring.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants