Re: [athena-tix-devel] Ticketing Transactions in ATHENA
Gary Moore
POST /transaction - Create a new transaction
PUT /transaction/{id} - Update a current transaction
GET /transaction/{id} - Get details of a transaction
HEAD /transaction/{id} - Whatever HEAD does.
DELETE /transaction/{id} - End a transaction without checkout and release all locks. This is entirely optional.
Cheers,
Gary
----- Original Message -----
From: "Gary Moore" <gary....@fracturedatlas.org>
To: "athena-tix-devel" <athena-t...@googlegroups.com>
Sent: Tuesday, September 28, 2010 1:12:25 PM
Subject: [athena-tix-devel] Ticketing Transactions in ATHENA
I'm designing an ATHENA helper to manage transactions in a ticketing
checkout scenario. This is the proposed "BUY TICKETS" flow:
0) Joe User finds tickets to buy
Example: Joe wants to see Jersey Boys on Friday night. He enters a
quantity of "2" and the date and pushes search button.
Client: Requests tickets from athena
ATHENA: Responds to the client with the ids of two available tickets.
Client: Presents tickets to Joe User.
1) Joe User says "Yes! I want these tickets"
Client: Asks ATHENA to begin a transaction and lock these tickets
POST /transactions
Body: {"tickets":[ARRAY_OF_TICKET_IDS]}
ATHENA:
- For each included ticket, do the following:
o Check that SOLD=FALSE. If so, return an error
o Check the TRANSACTION_LOCK_EXPIRES property to see if any of these
tickets are already involved in a transaction. If so, return an error
(see below)
o Create a transaction_id (use UUID)
o Set the following on the ticket: TRANSACTION_ID,
TRANSACTION_LOCK_EXPIRES to 180 seconds from now (somehow configurable),
TRANSACTION_LOCKED_BY to some client application identifier (likely an
API KEY) and TRANSACTION_LOCKED_IP to the IP of the client
- Return to the client a JSON response, including:
o An array of tickets involved in the transaction
o transaction_id
o lock_expires time
o status=OK
Client: Presents Payment interface to Joe User
2) Joe User enters Method of Payment (MOP)
Client: Asks ATHENA to extend the lock time so that Client can authorize
and confirm the MOP
POST /transactions/{id}
Body: {"tickets":[ARRAY_OF_TICKET_IDS], "id":transaction_id, "status":
"checkout"}
ATHENA: - Resets the lock expiration on each ticket
- Return to the client a JSON response, including:
o An array of tickets involved in the transaction
o transaction_id
o lock_expires time
o status=OK
3) Joe User confirms his MOP and that he wants to purchase these tickets
Client: Initials payment processing. If success, notifies ATHENA to mark
the ticket as sold.
POST /transactions/{id}
Body: {"tickets":[ARRAY_OF_TICKET_IDS], "id":transaction_id, "status":
"complete"}
ATHENA:
- For each included ticket, do the following:
o Mark SOLD=TRUE
o Create an ORDER, add ORDER_NUMBER to tickets
o Create or update a PEOPLE record
- Return to the client a JSON response, including:
o An array of tickets involved in the transaction
o transaction_id
o status=OK
4) Client displays confirmation
-------------
This leaves us with the following endpoints for the transaction
resource:
POST /transaction - Create a new transaction
POST /transaction/{id} - Update a current transaction
GET /transaction/{id} - Get details of a transaction
DELETE /transaction/{id} - End a transaction and release all locks. This
is entirely optional.
Do we need HEAD?
--
Visit: http://athena.fracturedatlas.org/tix
You received this email because you are subscribed to the "ATHENA Tix
Developers" group on Google Groups.
To post, email: athena-t...@googlegroups.com
To unsubscribe, email: athena-tix-dev...@googlegroups.com
For more, visit: http://groups.google.com/group/athena-tix-devel?hl=en