metadata of a single (predefined) process

[soxofaan]

(This is related to #310, but probably a non-breaking part of that)

all predefined processes are listed under /processes

as we are adding more non-official custom processes there is need to just list the metadata of a single process, e.g. under /processes/{process_id}.

[soxofaan]

note: the logical proposal of /processes/{process_id} would conflict with the current experimental implementation at vito of /processes/{namespace}

[m-mohr]

as we are adding more non-official custom processes there is need to just list the metadata of a single process

What are the reasons for that?

As there's a proposal up at #348, why do you not implement that and give feedback for it so that we can proceed with it? #348 is basically just waiting for feedback.

[soxofaan]

What are the reasons for that?

In short: process implementer and user are not the same user/team, the process goes through relatively quick development iterations, deployment is not immediate, the end user wants to quickly check what "version" of the process is "live" at the moment (e.g. check which parameters are exposed, check description ...)

[soxofaan]

As there's a proposal up at #348, why do you not implement that and give feedback for it so that we can proceed with it? #348 is basically just waiting for feedback.

It's been a while since I checked that indeed. I'll try to give it another look.

Side-note: would it be possible to host the documentation builds of feature branches somewhere? Reviewing these openapi.yaml diffs is not always straightforward.

[m-mohr]

In short: [...] the end user wants to quickly check what "version" of the process is "live" at the moment

Sounds like something that can easily by added by the clients right now? The JS client supports connection.describeProcess(id) for example, which is basically just just doing return this.processes.find(process => process.id === id);. The R client also supports describe_process. I'm happy to add this to the Python client via the open PR with a nice HTML visualization, if it's missing there. ;-)

Side-note: would it be possible to host the documentation builds of feature branches somewhere? Reviewing these openapi.yaml diffs is not always straightforward.

Not so easy as this also needs to be cleaned up afterwards, too. Also, redoc does hide some things (not supported or bugs) so a full review can only be done via the OpenAPI yaml. The easiest solution is to clone openeo-api, checkout the corresponding branch and just run redoc with npm run start.

[soxofaan]

Sounds like something that can easily by added by the clients right now

the thing is that in the use case that triggered me to submit this ticket, the user does not use a client, but "raw" HTTP requests, and they just want to visit a URL in a browser to check the process metadata.

But anyway, #348 seems to add GET '/processes/{namespace}/{process_id}', so I think we can just close this issue already (as duplicate)

[m-mohr]

@soxofaan Raw HTTP request in a browser I would consider being a bit out of scope. He could also easily connect to https://editor.openeo.org/?server=https://openeo.vito.be&discover=1 (save to bookmarks), type in the process id in the search field and get it nicely rendered. :-)