refunding tickets

[dadleyy]

@cpb2948 for the refund functionality, I think we should consider using

DELETE /tickets/{ticket_id}

instead of

POST /tickets/{ticket_id}

what do you think?

p.s I'm putting this here because I'm thinking we should could use github issues to talk about things before we actually track them in jira.

[cpb2948]

We could, i'm not really a fan of those obscure HTTP methods and shit ( PUT, PATCH, etc). I haven't really seem them used a lot. I guess here that makes sense, i'm just wondering if will ever need to post data.

[dadleyy]

I usually don't see many POST requests to endpoints dealing with a specific record - usually its PATCH, PUT or UPDATE.

But yea, instead delete, you could imagine if we had a status column on the ticket table, the concept of refunding things could be:

PATCH /tickets/1

{
  "status": "REFUND_PENDING"
}

[dadleyy]

also can we pluralize the user endpoint to keep it consistent?

[cpb2948]

that's not a bad idea. So when you register a user, you would essential make a PUT request then to create a user?

PUT /users

and it would create the users resource then?

[dadleyy]

post to create, put to update

POST /users

{
  "username": "....",
  "email": "....",
  "password": "...."
}

PUT /users/1

{
  "password": "new_password"
}

[cpb2948]

alright, yeah i can implement that, along with the DELETE functionality for refunding. The DELETE endpoint can be use to initiate a refund.

if you want the status of the ticket refund

GET /tickets/1

{ "status": "REFUND_PENDING" }

[dadleyy]

right. that would include everything else though, not just the status column though right? raffle_id, user_id, etc...

[cpb2948]

yeah

[dadleyy]

so once you make a jira ticket(s) for whatever you gotta do, lets close out these gihub issues.