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
|
### Problem Description
#### Background
The Government of Alberta manages the issuing of "well licenses" to companies or agencies who are interested in drilling for oil in the province. They want to deliver information about well licenses to companies and users through a mobile app and also a web app.
The task is to create a "well license" information API which will be consumed by the mobile app and a web app.
**Note:** This one API will service both apps.
A typical well license has the following structure (all fields are required):
* Well License ID
* Name of Applicant
* Well Type (list of available values)
* NFW: New Field Wildcat
* NPW: New Pool Wildcat
* DPT: Deeper Pool Test
* SPT: Shallower Pool Test
* DEV: Development Well
* Applying Company/Agency
* Latitude
* Longitude
* Township Name
* Date of License
* License Status (list of available values)
* Active
* Confidential
* Expired
#### Requirements
1. The API will generate:
* a list of all well licenses
* a list of all non-expired well licenses for a particular company/agency
* details of one well license
* a list of active well licenses for a particular township, for a specific company/agency
2. Anonymous users, without logging in, can query the API these four ways, and retrieve JSON responses.
**Note:** The assignment does not require any styled views over the JSON responses. We just want to see the JSON.
3. A confidential well should never have the following fields returned by the API:
* Name of Applicant
* Well Type
* Applying Company/Agency
4. Considering that this API will serve a mobile app, we want to reduce the number of API calls needed for one view request. So, the names of all the Well Types must always accompany a well license response, to populate a view drop-down list without making another API call.
5. Similar to '4', a listing of the different types of License Status must accompany any well license response.
#### Technical Notes
1. The API should ideally be deployed/hosted on heroku, or any hosted API endpoint of your choice that can be accessed by PetroFeed in Calgary.
2. Your submission can be developed using any technology/language you like.
3. This private Github repo has been created just for you. Please push your code to it for review.
## Design (Rough)
### Assumptions
* Name of applicant is the name of the employee at the company that submitted the application.
* Date of license is the date the license was issued.
* Assume perf isn't the focus, so no need to over-engineer with a denorm read model.
### Model
WellLicense (aggregate root)
* belongs_to applicant
* has_one well_type
* has_one location
* issued_at
* expired_at
* status
WellType (flyweight value object)
* id
* name
Applicant
* company
Location (value object)
* latitude
* longitude
* township_name
LicenseStatus (flyweight, state)
* id
### Endpoints
* GET /licenses - list of all well licenses
* GET /company/:id/licenses - list of all active licences for company
* GET /licenses/:id - details of a single license
* GET /company/:id/licenses?township=:township - list of active licenses for township, for company.
Start with a versioned api using urls cuz it's easy peasy. Won't worry
about token auth at this point.
What should i call this thing? hrmm....
|
