012 - URL structure
Purpose
This design document proposed a design for URLs for Monitor Space Hazards. The actual design is similar, but not all levels have been used to date.
Context and scope
URLs will be visible to the users in their address bar and in the notifications they are sent out.
We can expect most users to come in at the homepage in most instances.
The top level domain is out of scope for this document but is assumed to be GDS-compliant and along the lines of
https://monitor-space-hazards.service.gov.uk/
Goals and non-goals
Goals
- A good URL is one which is unique, permanent, and hackable.
- It should be compliant with the GOV.UK URL standards.
Monitor Space Hazards has a very limited number of URLs which can be structured simply to easily comply with the above principles.
Non-Goals
- Avoiding inconsistencies
The actual design
Event URLs
The generic event structure should be in the format:
/[event type]/[event ID]/[view]?[modifier]
Event URLs will be in the format
/[event type]/[event ID]- event landing page
Alert URLs will be in the format
/[event type]/[event ID]/[alert]- individual alert page
Example conjunction event URLs
| Page | URL stage 1 | URL stage 2 | URL stage 3 |
|---|---|---|---|
| Homepage | / |
||
| Conjunction landing page | /conjunctions |
||
| Conjunction event | /conjunctions |
/xxxx-yyyyy-zzzz |
|
| Conjunction alert | /conjunctions |
/xxxx-yyyyy-zzzz |
/alert |
Example re-entry event URLs
| Page | URL stage 1 | URL stage 2 | URL stage 3 |
|---|---|---|---|
| Homepage | / |
||
| Re-entries landing page | /re-entries |
||
| Re-entry event | /re-entries |
/re-11111111-1111 |
|
| Re-entry alert | /re-entries |
/re-11111111-1111 |
/alert |
Satellite URLs
The generic satellite structure should be in the format:
/satellites/[satellite ID]
Where the satellite ID is the NORAD ID (North American Aerospace Defense catalogue number) assigned to the object.
Satellite URLs will therefore be in the format
/satellites- all satellites visible to the user/satellites/[satellite ID]- individual satellite page
Example satellite URLs
| Page | URL stage 1 | URL stage 2 | URL stage 3 |
|---|---|---|---|
| Organisation satellites page | /satellites |
||
| Satellite page | /satellites |
/12345 |
|
| Satellite page | /satellites |
/12345 |
/ephemeris-upload |
Account URLs
Settings and management is available from the /account section for the service.
Example admin URLs
| Page | URL stage 1 | URL stage 2 | URL stage 3 |
|---|---|---|---|
| View contact details | /account |
/contact-and-organisation-information |
|
| View and edit notification settings | /account |
/notification-settings |
|
| View and edit notification thresholds | /account |
/event-notification-thresholds-settings |
|
| Organisation information | /account |
/organisation |
|
| Add new user | /account |
/add-new-user |
Example static page URLs
There are a number of static pages and sundry information that is served from a headless CMS CosmicJS. Generally these will be available from the footer of the service and other linked locations.
| Page | URL stage 1 | URL stage 2 | URL stage 3 |
|---|---|---|---|
| Definitions | /page |
/definitions |
|
| Support and guidance | /page |
/support-and-guidance |
|
| Conjunction event analysis process and data sources | /page |
/conjunction-analysis-information |
Sign in URLs
The sign in service uses an external authentication provider Auth0 and is available from the start page /
Alternatives considered
- Events: Contact and upload pages being top level pages eg
/contact/[event ID]rather than vice versa.- Rejected to ensure that the URL remained hackable and that contacts to orbital analysts were always related to a specific event.
- Satellites: Satellite IDs not being in their own directory, ie a Satellite URL would be just
[satellite ID]- Rejected to ensure that the URL remained hackable and that all satellites connected to an organisation could be collected at
/satellites
- Rejected to ensure that the URL remained hackable and that all satellites connected to an organisation could be collected at
- Many different UUIDs for events were considered as part of the UID design paper.
Cross-cutting concerns
URLs are themselves dependent on the UUID structure for an event. The unity between UUID and URLs allows for strong human-readable debugging and analysis.