Add further Messages for more IDS native Operations

[sebbader]

We just realized that the current Messages need to be extended to reflect more operation semantics. For instance:

• PUT or create/update semantics: not only for metadata but also for productive data
• More http interactions encoded (@mkollenstart ?)

Let's use this issue to collect use cases and needs, and then prepare the update for the next IM version.

[mkollenstart]

Ideally, the whole set of HTTP methods should be supported, to provide no limitations. In any case the following methods should be at least supported:

• GET
• POST
• PUT
• DELETE
• PATCH

Other methods (HEAD, CONNECT, OPTIONS, TRACE) could be relevant, but I don't have a concrete scenario where I would use these.

The other information that is relevant are the HTTP headers, for which the question is how to model these. Should they be in a sort of map structure, or should we create semantics for standard headers (Accept, Host, etc) and a map for custom headers (for instance X-B3 headers for distributed tracing)

[sebbader]

Hi Maaren,

I agree that the HTTP verbs are the best reference for this, even though incomplete (subscribe is missing, for instance).

However, at the moment I read the message types as a combination of the operation semantics AND the target type: ResourceAvailableMessage := PUT + Resource as Target

That gives me a hard time as it will require a lot of different messages... Do you think we can find a reasonable approach here?

[jlangkau]

HEAD, OPTIONS are being used in LDP – so I like those 😉

[sebbader]

I am not sure about a concrete use case for HEAD and OPTIONS for either ids:Resource, ids:Connector, ids:Participant or ids:Contract...

[sebbader]

Class	Read	Create	Update	Delete	Read Metadata	Subscribe	Execute	Notify
Resource	DescriptionRequestMsg	ResourceAvailableMsg					todo
Connector
Participant
Contract

Can we fill such a table? Would that help us?

[sebbader]

With "we" I mean "all of us", not "myself", just to clarify things :-)