Per T288127: Design the Example Node API we intend to implement this iteratively. First steps seem to be:

1. add the endpoint to spec.yaml, for documentation purposes and to clarify the initial path/behavior of the endpoint
2. create a minimal endpoint implementation that returns a hard-coded "Hello World" string
3. create one or more tests for this level of implementation

It probably makes sense to create subtasks for this.

Added three subtasks. This gets the basic boilerplate in place, which we can then expand on to fulfill the other acceptance criteria.

Looking a bit more, I don't see a reason not to use a simple hash of the response (md5 or whatever) as the etag value for the example api.

Also, kinda cool that the etag header documentation at mozilla.org uses a wiki as an example:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag

It won't actually do much, but it at least provides a server-side example of how an ETag might be generated, and reinforces the idea that they're good things to have.

I suppose we could support an in-service cache that, if it detects If-None-Match (and has a cache entry for the associated etag) to return a 304 instead of the actual response. That'd be even more contrived for the example api, as regenerating the response is pretty cheap. But it'd give an example of that header's purpose. Not sure it is worth it, and if we did it we should add comments to the code explaining that it is just an example to illustrate functionality and not the way a real service should implement caching. Opinions welcome.