Investigate feasibility of making service_type optional in Update

[james-rae]

the /update endpoint requires a service type to be provided. Joost has suggested to make this optional, as you may not remember what was used.

The original request is stored internally in the couchDB, so it should be retrievable inside the update command.

Investigate:

• that the above idea will actually work
• if there are any problematic situations that arise
• what kind of error handling is required if someone attempts to update a URL that points to a service that does not match the original service_type
• amount of effort to make the change.

[barryytm]

Here is the conclusion to my investigation

• The idea of making update optional should work. What update does is to update the payload type then using it to reconstruct a layer node to replace the existing one but still being mapped by the same registered key (evidence).
• Theoretically, the possible problematic situations should also be a subset of the possible problematic situations register has. If there is a problem occurs that is not in that subset, then it will most likely occur in the logic of update.
• Since the idea of update is basically to reconstruct a new layer node under the same key. The error handling should be somewhat similar to register excluding all the key mapping related errors.
• It shouldn't take long to make the change but might require some extensive testings once implemented.

Feel free to comment on my findings and please do correct me if anything I said above is untrue or doesn't make sense.