Webservice: PUT URIs are not REST-like

[jri]

At the web tier the Core Service's updateTopic and updateAssociation methods are currently accessed through these requests:

PUT /core/topic
PUT /core/association

The topic resp. association ID is not contained in the URI but in the message body (as part of the respective model representation).

This is not REST-like and might undermine the browser's own caching capability.

The REST principle requires a unique URI for each resource, to be uniformly used with GET and PUT. So, DM's PUT requests should be:

PUT /core/topic/{id}
PUT /core/association/{id}

These URIs might allow the browser to issue the PUT requests conditionally (that is with a If-Unmodified-Since header) and thus helps avoiding the lost update problem (see #479).

[jri]

Webservice: PUT URLs are REST-conform (#482).

BREAKING CHANGE

The topic/association update requests are now REST-conform.

REST API:

    PUT /core/topic/{id}
    PUT /core/association/{id}

The respective ID is now part of the request URI.

If your plugin or external application constructs the update URL itself it must be adapted.
However if your plugin uses these Webclient's API methods no update is required:

    dm4c.do_update_topic()
    dm4c.do_update_association()
    dm4c.restc.update_topic()
    dm4c.restc.update_association()

Note 1: the Webclient API and the Core Service API have not changed. Only the REST API has.

Note 2: in the update requests shown above the respective ID now appears redundantly at 2 spots: 1) in the request URI, and 2) like before in the message body (the model representation). Crucial is the ID in the request URI.

About the ID in the message body: it is optional. Weather it is -1 or not specified at all makes no difference. However if it is specified (that is unequal to -1) it must match the ID in the request URI. If the ID is specified but does not match the ID appearing in the request URI an exception is thrown.

Close ticket 482.

Changeset: a1a02b50a527d1d64ebac8d097965fabd547a7e5