Tobias Girschick wrote:
> A further problem with complete URIs as IDs is, that if one decides to
> move the server or just change the port, all the IDs are wrong!
>   
If one moves the server/port , perhaps it needs to be considered a new
service ?  Why you would consider this an issue?

Regards,
Nina
> On Tue, 2009-09-29 at 14:16 +0200, Tobias Girschick wrote:
>   
>> Hi,
>>
>> While revising the API 1.0 there arose some controversy about IDs for
>> features, feature definitions, references and so on.
>>
>> As far as we I know there has been no definitive decision made up to
>> now. Please correct me if I am wrong here.
>>
>> What we are using at the moment as IDs for feature definitions and
>> references is full URIs, e.g. something like this:
>>
>> http://lxkramer13.informatik.tu-muenchen.de:8180/OpenTox/feature_definition/CDK_topoShape
>> http://lxkramer13.informatik.tu-muenchen.de:8180/OpenTox/reference/CDK_topoShape
>>
>> This seems to be very nice and useful. But there arises one conflict
>> with feature IDs as the API specifies the following URI to GET a
>> specific feature:
>> /feature/compound/{cid}/feature_definition/{f_def_id}
>>
>> The URI won't work if I just blindly insert the compound or feature
>> definition ID here, as they both are fully qualified URIs. 
>>
>> If we use just something like CDK_topoShape as ID instead of a URI, we
>> have the problem that this would have to be unique over the whole
>> OpenTox system to prevent mix ups.
>>
>> Is there a clever way to solve this?
>>
>> Regards,
>> Tobias
>>
>>