JodApp API

API is grouped according to the user types in Jod.

Main reason for this is there are different business logic for users acting on the same model.

Context

Creating a Job

Careers::Job and Gig::Job is created by an Org User (i.e. Org::UserProfile) but not a Careers User (Careers::UserProfile).

• Careers User applies to a Careers::Job, but not an Org User.
• This means that the Careers User cannot have access to the endpoint (e.g. POST /careers/jobs).

Instead of having a RBAC system, we can simply split endpoints into different groupings.

• Backend then would authenticate if the request was made by a Careers or Org user.

This is simpler than having a RBAC system.

Fetching Jobs

An Org User can only see jobs that belong to their company when using their Employers Dashboard.

• However, a Careers User can see all jobs, regardless of the company.

Rather than having a complex RBAC system, we can have clear, distinct boundaries in our API design.

API "Grouping"

Just like how rails has namespacing, we can namespace our APIs.

As of 14 July 2025, we are designing the system to support two services:

• Gig
• Careers (a.k.a JodBoard)

And we have two types of users per service:

• Gig
  • Gig::UserProfile
  • Org::UserProfile
• Careers (a.k.a JodBoard)
  • Careers::UserProfile
  • Org::UserProfile

We will append the user type to the API paths.

Take for example a simple resourceful endpoint to create a Careers::Job:

• POST /careers/jobs

Now we append the user type (org-user) to the path:

• POST /org-user/careers/jobs

deconstructed endpoint	description
POST	creating
/org-user	as an org user
/careers	in the domain "careers"
/jobs	a job in the backend (which is the model Careers::Job)

Likewise for a "careers user", we would have the endpoint GET /careers-user/careers/jobs

deconstructed endpoint	description
GET	fetching
/careers-user	as a careers user
/careers	in the domain "careers"
/jobs	a job in the backend (which is the model Careers::Job)