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

Take args from JSON post data #8

Open
wants to merge 9 commits into
base: master
Choose a base branch
from
Open

Take args from JSON post data #8

wants to merge 9 commits into from

Conversation

abrandemuehl
Copy link
Contributor

Makes a change in the API to allow for multiple locations to be passed

Resolves #7

Makes a change in the API to allow for multiple locations to be passed

Resolves #7
@abrandemuehl
Copy link
Contributor Author

The post data should look like:

{"items": ["A1", "B2", "C3"]}

@abrandemuehl abrandemuehl requested a review from rauhul April 3, 2017 15:27
@sameetandpotatoes
Copy link
Member

@abrandemuehl So would this require the merch service to make one request to /vend with all items? Should this also return an array of successes/failures so that I know which transactions specifically succeeded?

@abrandemuehl
Copy link
Contributor Author

Right now, if it fails in the middle, then problems will happen. I'll update it to catch failures and return which drinks were successfully vended

@abrandemuehl
Copy link
Contributor Author

How would you prefer success/failure of individual vends be indicated? I can return a combination of the index of what failed and the location.

Also, if the vend_queue feature gets put through, it'll make vending asynchronous with respect to the api requests made. We could either have the async vend queue notify the merch service at the end of the vend, or we could ditch the async vend queue for the for loop in this PR. They both work, but this one will be simpler

The machine will return the index of the vend that failed
@sameetandpotatoes
Copy link
Member

sameetandpotatoes commented Apr 3, 2017

Hmm, well ideally I was thinking something like this:

I send:

{
    "transaction_id": 1,
    "items": [ "A1", "B2", "C3" ]
}

and get back:

{
   "transaction_id": 1,
   "items": [
       {
             "error": null,
             "location": "A1"
       }, {
             "error": "No item present",
             "location": "B2",
       }, {
             "error": null,
             "location": "C3"
       }
   ]
}

It would be nice to get that same transaction id back so with a vend queue it's clear what transaction these items belonged to (as transaction id comes from the merch service's database).

I'm open to suggestions though.

@abrandemuehl
Copy link
Contributor Author

Updated

@abrandemuehl
Copy link
Contributor Author

I've added the documentation for the API to the readme

@abrandemuehl
Copy link
Contributor Author

What do you think about the final result @sameetandpotatoes. I'll get this tested on the machine sometime this week.

README.md Outdated
Every request through the API has a token in the header that is unique to groot.
This way, only groot can make requests to vend things.
The token is stored in the request header.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be something like

"Requests to the device must contain a valid token in the Authorization Header for a request to be processed.
As of now the only token will be given solely to the groot merch service, so if you wish to make merch requests go through groot. "

Also rename the header field from Token to Authorization, better match with web conventions (may require change by @sameetandpotatoes on the service side)

@sameetandpotatoes
Copy link
Member

Yeah this looks good to me. Before this merges though, I will need to make the corresponding change in groot-merch-service and then we should probably test that too.

Copy link
Member

@rauhul rauhul left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

InvalidLocationError should be thrown for any location the machine physically cannot vend. If, for some reason, Groot ever needs to press another key we can create a different endpoint to do so.

Copy link
Member

@rauhul rauhul left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems good to the guy that doesn't know python 👍

@rauhul
Copy link
Member

rauhul commented Apr 5, 2017

@sameetandpotatoes can you make those changes to the service

@@ -45,12 +45,28 @@
def hello_world():
if request.headers.get('TOKEN', '') != token_value:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Change this from TOKEN to Authorization

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sameetandpotatoes Change this on service side as well ^

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sameetandpotatoes
Copy link
Member

acm-uiuc/groot-merch-service#11

Still needs to be tested

@abrandemuehl
Copy link
Contributor Author

@narendasan Does that fix your concern?

Copy link
Member

@narendasan narendasan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lgtm

@abrandemuehl
Copy link
Contributor Author

I've added the status endpoint, which will tell the service if the machine is ready to vend, as well as fixed up the errors that exist

The flask app is now multithreaded. Only one request will handle merch
at a time through /vend, and the /status endpoint will return 200 if the
machine is available to vend, and 503 if it is currently vending
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

Successfully merging this pull request may close these issues.

4 participants