Return to Answer

You'll find opinionated answers on this because it's subjective to the use case. There is no right answer here. Ideally, you design the API to suit your use case the best.

1. event/:event-id/members vs /members Questions I'd ask myself: Will the "member" resource stand alone? Fox ex:

• Will I need to fetch members across events (for say performing analytics) ? I can always GET /members and filter on event-id as a query param.

• Do I want to add multiple endpoints to support cleaner usage, like POST event/:id/members and GET /members/:id?

2. I've found that nesting in the manner you mention (3 level) does not scale well for the same reason above - today you nest members under mini-event. Tomorrow, if you need to access members across events (analytics as an example), you'd have to duplicate an endpoint. If it was a root level, again, simply add parameters.

In your case, if a member can belong to both an event and mini-event, you're already having multiple endpoints. Avoid that, it makes documentation harder.

Avoid something like PATCH event/:event-id/mini-event/:mini-event-id/members/:member-id. PATCH members/:id is easier to work with

In conclusion, here is what you can do. Use GET for /members/ and /mini-events/ with query params. POST, PUT, PATCH and DELETE for /events/:event-id/members/:member-id and /events/: event-id/mini-events/:mini-event-id.

Some relevant reading https://martinfowler.com/articles/richardsonMaturityModel.html

You'll find opinionated answers on this because it's subjective to the use case. There is no right answer here. Ideally, you design the API to suit your use case the best.

1. event/:event-id/members vs /members Questions I'd ask myself: Will the "member" resource stand alone? For example:

• Will I need to fetch members across events (for say performing analytics) ? I can always GET /members and filter on event-id as a query param.

• Do I want to add multiple endpoints to support cleaner usage, like POST event/:id/members and GET /members/:id?

2. I've found that nesting in the manner you mention (3 level) does not scale well for the same reason above - today you nest members under mini-event. Tomorrow, if you need to access members across events (analytics as an example), you'd have to duplicate an endpoint. If it was a root level, again, simply add parameters.

In your case, if a member can belong to both an event and mini-event, you're already having multiple endpoints. Avoid that, it makes documentation harder.

Avoid something like PATCH event/:event-id/mini-event/:mini-event-id/members/:member-id. PATCH members/:id is easier to work with

In conclusion, here is what you can do. Use GET for /members/ and /mini-events/ with query params. POST, PUT, PATCH and DELETE for /events/:event-id/members/:member-id and /events/: event-id/mini-events/:mini-event-id.

Some relevant reading https://martinfowler.com/articles/richardsonMaturityModel.html

You'll find opinionated answers on this because it's subjective to the use case. There is no right answer here. Ideally, you design the API to suit your use case the best.

1. event/:event-id/members vs /members Questions I'd ask myself: Will the "member" resource stand alone? Fox ex:

• Will I need to fetch members across events (for say performing analytics) ? I can always GET /members and filter on event-id as a query param.

• Do I want to add multiple endpoints to support cleaner usage, like POST event/:id/members and GET /members/:id?

2. I've found that nesting in the manner you mention (3 level) does not scale well for the same reason above - today you nest members under mini-event. Tomorrow, if you need to access members across events (analytics as an example), you'd have to duplicate an endpoint. If it was a root level, again, simply add parameters.

In your case, if a member can belong to both an event and mini-event, you're already having multiple endpoints. Avoid that, it makes documentation harder.

Avoid something like PATCH event/:event-id/mini-event/:mini-event-id/members/:member-id. PATCH members/:id is easier to work with

In conclusion, here is what you can do. GET /members/ and GET /mini-events/ with query params. POST, PUT, PATCH and DELETE for /events/:event-id/members/member-id and /events/: event-id/mini-events/:mini-event-id.

Some relevant reading https://martinfowler.com/articles/richardsonMaturityModel.html

You'll find opinionated answers on this because it's subjective to the use case. There is no right answer here. Ideally, you design the API to suit your use case the best.

1. event/:event-id/members vs /members Questions I'd ask myself: Will the "member" resource stand alone? Fox ex:

• Will I need to fetch members across events (for say performing analytics) ? I can always GET /members and filter on event-id as a query param.

• Do I want to add multiple endpoints to support cleaner usage, like POST event/:id/members and GET /members/:id?

2. I've found that nesting in the manner you mention (3 level) does not scale well for the same reason above - today you nest members under mini-event. Tomorrow, if you need to access members across events (analytics as an example), you'd have to duplicate an endpoint. If it was a root level, again, simply add parameters.

In your case, if a member can belong to both an event and mini-event, you're already having multiple endpoints. Avoid that, it makes documentation harder.

Avoid something like PATCH event/:event-id/mini-event/:mini-event-id/members/:member-id. PATCH members/:id is easier to work with

In conclusion, here is what you can do. Use GET for /members/ and /mini-events/ with query params. POST, PUT, PATCH and DELETE for /events/:event-id/members/:member-id and /events/: event-id/mini-events/:mini-event-id.

Some relevant reading https://martinfowler.com/articles/richardsonMaturityModel.html

True that you'll find opinionated answers on this. That's because it's subjective to the use case. There is no right answer here. Ideally, you design the API to suit your use case the best.

1. event/:event-id/members vs /members Questions I'd ask myself: Will the "member" resource stand alone? Fox ex:

• Will I need to fetch members across events (for say performing analytics) ? I can always GET /members and filter on event-id as a query param.

• Do I want to add multiple endpoints to support cleaner usage, like POST event/:id/members and GET /members/:id?

2. I've found that nesting in the manner you mention (3 level) does not scale well for the same reason above - today you nest members under mini-event. Tomorrow, if you need to access members across events (analytics as an example), you'd have to duplicate an endpoint. If it was a root level, again, simply add parameters.

In your case, if a member can belong to both an event and mini-event, you're already having multiple endpoints. Avoid that, it makes documentation harder.

Avoid something like PATCH event/:event-id/mini-event/:mini-event-id/members/:member-id. PATCH members/:id is easier to work with

In conclusion, here is what you can do. GET /members/ and GET /mini-events/ with query params. POST, PUT, PATCH and DELETE for /events/:event-id/members/member-id and /events/: event-id/mini-events/:mini-event-id.

Some relevant reading https://martinfowler.com/articles/richardsonMaturityModel.html

You'll find opinionated answers on this because it's subjective to the use case. There is no right answer here. Ideally, you design the API to suit your use case the best.

1. event/:event-id/members vs /members Questions I'd ask myself: Will the "member" resource stand alone? Fox ex:

• Will I need to fetch members across events (for say performing analytics) ? I can always GET /members and filter on event-id as a query param.

• Do I want to add multiple endpoints to support cleaner usage, like POST event/:id/members and GET /members/:id?

2. I've found that nesting in the manner you mention (3 level) does not scale well for the same reason above - today you nest members under mini-event. Tomorrow, if you need to access members across events (analytics as an example), you'd have to duplicate an endpoint. If it was a root level, again, simply add parameters.

In your case, if a member can belong to both an event and mini-event, you're already having multiple endpoints. Avoid that, it makes documentation harder.

Avoid something like PATCH event/:event-id/mini-event/:mini-event-id/members/:member-id. PATCH members/:id is easier to work with

In conclusion, here is what you can do. GET /members/ and GET /mini-events/ with query params. POST, PUT, PATCH and DELETE for /events/:event-id/members/member-id and /events/: event-id/mini-events/:mini-event-id.

Some relevant reading https://martinfowler.com/articles/richardsonMaturityModel.html