Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

System Control request and response are REST-awkward #2

Open
pizthewiz opened this issue Dec 3, 2014 · 7 comments
Open

System Control request and response are REST-awkward #2

pizthewiz opened this issue Dec 3, 2014 · 7 comments

Comments

@pizthewiz
Copy link

A couple of things stick out:

  • A POST is used for a value fetch and for a value change
  • Two resources, VOLUME and MUTED are wrapped by a single edge, so when requesting the volume, we also get the muted state
  • The level property provides the value for a GET_VOLUME request
@jsli
Copy link
Member

jsli commented Dec 4, 2014

Thanks for your proposal.
We will fix it ASAP.

@pizthewiz
Copy link
Author

Great! In that case let me make a more clear suggestion:

  • An API edge for each resource
  • GET to fetch the value and POST to change it
  • Return 200 on a successful GET and 201 on a successful POST

The value sent and received could be in a common parameter (like value below), or it could be in something edge specific like volume and mute.

Set volume:

$ curl -X POST -H "Content-Type: application/json" -d '{"value": 0.75}' \
http://localhost:9431/system/control/volume

Get volume:

$ curl -X GET http://localhost:9431/system/control/volume
{"value":0.75}

Set muted state:

$ curl -X POST -H "Content-Type: application/json" -d '{"value": true}' \
http://localhost:9431/system/control/mute

Get muted state:

$ curl -X GET http://localhost:9431/system/control/mute
{"value":true}

@jsli
Copy link
Member

jsli commented Dec 5, 2014

Thanks for your great suggestion! I'll implement it in a few days.
BTW, sometimes my english is not good enough to get all your points, if anything I misunderstood, just let me know.

@pizthewiz
Copy link
Author

No problem, I'm glad to help out.

By the way is flingd-coffee the Flint daemon running on the Matchstick? I thought it was just a software testing solution, but it seems very full-featured.

@jsli
Copy link
Member

jsli commented Dec 5, 2014

Thanks your help!
Yes, the Flint daemon is running on the Matchstick, and the Matchstick is the first reference product of Flint. And flingd-coffee is a full implementation of Flint, but not just a software test solution, and flingd-coffee will be more perfect with your guys' help.
Did I described clearly? I'm sorry about my poor english, if any confusion you have, let me know.

@pizthewiz
Copy link
Author

No that makes perfect sense, so if we run into issues with flingd-coffee we should report them as it is also running on the Matchstick. Thanks!

@jsli
Copy link
Member

jsli commented Dec 5, 2014

yes, the Matchstick should integrate these useful patches.

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

No branches or pull requests

2 participants