implicit exact mapping between http verbs and operations, or not?

[michielbdejong]

The names GetOperation, PostOperation, etc. imply that there would be one operation per http verb (and then maybe HeadOperation and GetOperation would reuse common code between them, and same for PostOperation and PutOperation?).

If it's really meant to be one operation per http verb then a note about that would make that more explicit.

If not, then for instance PostOperation is not a really good name for what that operation does, it might be more along the lines of 'CreateOperation', right?

[RubenVerborgh]

Yeah, that's not a crucial decision. The OperationFactory shields LdpHandler from the request-to-operation mapping, so it can be anything that fits.

I think it is meaningful to keep a close relation to the LDP specification, so PostOperation (or perhaps even LdpPostOperation) keeps a close relation to what is intended there, whereas CreateOperation is an interpretation of what LDP POST does.

I don't mind in any way; they are more illustrative and not the distinctive part of the architectural design.

There might be cases for even more specific LDP operations, like GetContainerOperation and GetResourceOperation, to reduce the complexity of a single operation. This is then the point where OperationFactory makes the decision (or perhaps a generic GetOperation that then delegates to the appropriate more specific one). That's up to implementers at this level of detail.

[acoburn]

With Trellis, I also separate the HTTP operations into per-method classes (PostHandler, GetHandler, etc). I have seen other LDP implementations that combine them all together, and the code just gets really, really complex -- it's not wrong, but it's harder to maintain. And separating the methods by conceptual operation (create, update, read) also gets a little messy, because PUT may be used to create or update, and PUT to update ends up being quite different than PATCH to update. And even the distinction between PUT and POST to create may have subtle differences, implementation-wise.

So, from a purely pragmatic perspective, these per-HTTP-method classes ends up being nicer to work with. Also, when debugging, if there is an error in, say, a PUT request, you know right where to look.

[michielbdejong]

when debugging, if there is an error in, say, a PUT request, you know right where to look.

good point!

[RubenVerborgh]

This is now implemented via a handler mechanism in 9e68331473c5e9f79281098ad97c9ad95e3c1e5c.