Patch company project wells and project wells with one endpoint

Hi all! I’ve been working with the ComboCurve API lately and it’s been working well for my use case so far.

I was wondering if there might be any interest in adding a new endpoint that combines both patch endpoints for projects/:projectId/wells and wells to allow submitting a single request containing a mix of company-scoped wells and project-scoped wells for a project.

I’d like to avoid storing scope to avoid it potentially becoming stale (e.g., during import the well might be company-scoped but later converted to project-scoped), so my update flow currently looks like this:

  1. get a list of project-scoped chosen IDs from the projects/:projectId/wells endpoint
  2. get a list of company-scoped chosen IDs from the projects/:projectId/company-wells endpoint
  3. filter my list of updates to project-scoped chosen IDs (based on the response in 1) and send a patch for project-scoped wells
  4. filter my list of updates to company-scoped chosen IDs (based on the response in 2) and send a patch for company-scoped wells

Ideally I’d like to send the unfiltered list containing both project-scoped and company-scoped wells (combining 3 and 4) which would remove the need to query scope (skipping 1 and 2).

This would be a minor improvement overall but would reduce the chattiness for update flows similar to this quite a bit (1 request instead of 4 for smaller projects, probably more substantial savings for larger projects). Technically if you already know the full list of chosen IDs in the project, you could skip 1 or 2 (e.g., knowing which wells are project-scoped implies the rest are company-scoped), but it could be useful to query both for validation anyway.

Similarly for querying well header data from a project, it would be useful to be able to query all wells (both project- and company-scoped) in a project at a single endpoint instead of having to hit both endpoints (projects/:projectId/company-wells and projects/:projectId/wells). Also not a big deal but would improve the ergonomics slightly - I’d guess most people will query both anyway.

Just thought I’d share this feedback in case there’s some interest in improving the ergonomics here slightly in case there are other people using a similar flows for updating/querying well headers in a project. Thank you!

2 Likes

Hey @josh,
thanks for taking the time to write this feedback! The team will discuss your suggestions internally and when we come to some sort of conclusion I’ll let you know.

Happy Holidays,
-Harry

1 Like