-
Notifications
You must be signed in to change notification settings - Fork 4
/
new-route-convention.txt
124 lines (92 loc) · 5.24 KB
/
new-route-convention.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
before I get too deep into the weeds of the current API setup, perhaps some rationality,
or at least some system that isn't the present total chaos.
TOP LEVEL:
based on AUTHENTICATION STYLE. Some of the names are a touch awkward because the intent
is to reserve data type names (tourn, school, chapter).
/auto - public jobs with internal effects. Autoqueue executors basically. Restricted
by origin IP of the address; must be from within the confines of the server env
as defined in config.json
/ext - External APIs requiring an account with an API key to determine their scope.
The API keys are tied to user accounts, and the user must have an api_auth_method
person_setting (only settable by us on the backend for now).
/tab/:tournId - APIs and functions related to tabulation of a tournament. Checks on tourn
permissions. All event-specific permission accessible APIs should live under /event.
All category-specific permission APIs should live under /category. /all is the
source of APIs that anyone with a tournament can access, to set up things like
the user specific access for menus and such.
Top level types under the tournament ID that support fine grained permissions are
/category
+ /judge
+ /event
++ /round
++ /entry
/coach/:chapterId - APIs and functions related to school/chapter administration.
Depends on chapter permissions
/user - Everything that is only personalized to a user's own account. Student
landing page, judge landing page, personal results records, paradigm
editing. person ID is embedded in the session.
/glp - Only those with godlike powers may enter here. person ID is embedded in
the session
/local - Managers of various subdivisions of Tabroom. This will include
/circuit/:circuitId
/diocese/:dioceseID
/region/:regionId
/district/:districtId
CONVENTION:
Underneath each top level should be the data area being operated on, followed by the
ID of that area, followed by a functional breakdown.
/tab/12345 -> get -> get a data backup of the whole tourn. post uploads a backup file.
/tab/12345/setting/nsda_district -> get/post/put/delete -> get or affect this tourn setting
/tab/12345/event/14481/round/12345 -> get -> get databackup like above. post uploads the same.
/tab/44151/event/44481/round/12345/schemat -> get a schematic only representation of a round.
[depending on what I do with the front end, this type of thing may not be desirable?]
Reserve plural for multiple reports based on this as primary for a one-to-many relationship:
/tab/12345/events -> get -> get all events from the tourn
/tab/12345/sites -> get -> get all sites
/tab/12345/status -> get -> get current event status
These could all be the same function but hide that from the endpoint tree and user
because why should they care.
/tab/12345/event/12466/rounds -> get all the rounds in this event
/tab/12345/timeslot/23586/dashboard -> get -> get all timeslot dashboard status
/tab/12345/round/233485/dashboard -> get -> get all round dashboard status
/tab/12345/event/9535385/dashboard -> get -> get all event dashboard status
Functional things should be simple commands defaulting to POST, placed in the tree underneath
the thing operated on. Don't go too nuts with the escalating trees of doom; the single smallest
necessary ID numbers are best. Actions should as much as possible reflect what data is affected
or added or something. Parameters besides the id of the target operand should be in the body.
use 'place' as a verb that is particular to the pairing/schematic/etc process. Always use a verb
when the backend is going to be manipulating data instead of simply delivering or accepting it.
/tab/round/151551/placeEntries -> POST -> pair the round
/tab/round/151551/placeJudges -> POST -> place the judges
/tab/round/151551/placeRooms -> POST -> place the rooms
Attach mass actions below the parent container
/tab/event/58125/rounds/placeEntries -> POST -> pair all the event's rounds
/tab/timeslot/395585/rounds/placeJudges -> POST -> place all the timeslot's judges
Spec after everything if available
/tab/event/58125/rounds/placeEntries/prelims -> POST -> pair all the event's prelims
And then the results and whatever else live in the same place
/tab/event/58125/results overall results
/tab/event/58125/results/speakers overall speaker results
/tab/round/3558125/results results as of round whatever
/tab/sweeps/3595/results results of the sweepstakes protocol.
CHECKLIST OF PLACES THE API PATHS ARE REFERENCED IN LEGACY CODE:
#./web/funclib/docshare_rooms.mas
#./web/funclib/nsda/nats_appearances.mas
#./web/funclib/push_notifications.mas
#./web/funclib/send_notify.mas
#./web/lib/Tab/General.pm
./web/panel/judge/jpool.mhtml
./web/panel/judge/menu.mas
./web/panel/judge/nats_pool_totals.mhtml
./web/panel/schemat/blast_message.mas
./web/panel/schemat/blast_pairing.mas
./web/panel/schemat/section_blast.mhtml
./web/panel/schemat/settings_edit.mas
./web/panel/schemat/show.mhtml
./web/setup/tourn/access.mhtml
./web/tabbing/publish/index.mhtml
./web/tabbing/status/dashboard.mhtml
./web/tabbing/status/status.mhtml
./web/user/enter/authorizenet.mas
./web/user/enter/paypal.mas
./web/user/judge/ballot_rubric.mas