Conflicting resource type/trait properties


#1

The spec does not specify how to handle resource types and traits with properties that conflict with the properties of the resources or methods they are applied to, or with properties from other resource types and traits applied to the same resources/methods.

E.g. what should happen when a trait that defined a query parameter of “foo” is applied to a method that already defined a query parameter of the same name, or what should happen when a resource type is applied to a resource with a method that already defined a response with the same status code with the same media type but a different body schema.

A parser can either choose to raise an exception or to allow the overriding of the properties. If the choice is overriding, the spec should specify which properties take precedence, trait over method, resource type over resource, or vice versa (actually, also trait over resource type, as a type can contain a trait).

If overriding rather than raising an error it the desired behavior, presumably the more sensible option is for resource/method properties to have prevalence over resource type/trait properties to allow for resource/method to become more specialized, akin to a child class overriding a parent’s attributes.

Even so, there is still a question of which takes priority when a property of a trait conflicts with a property of a property of a resource type, or when a property a trait conflicts with the property of another trait. The answer to the later will depend on whether traits are processed left to right, or right to left as they are declared. A special issue with the trait/trait priority is which should take higher precedence, traits on a method or traits inherited by a method from a resource. Presumably the method trait should have a higher precedent since its applied more specifically. But all this needs to be spelled out in the spec.


#2

Assuming that traits/resource types with conflicting parameters should be merged, another problem is how to handle the merging named attributes with multiple types.

If you must merge a named attribute with a single type and a named parameter with multiple types, what do you do?

If the single type parameter is the overriding one, you could replace the multiple types with the single overriding type. Alternatively, you could try to match the type of the single type parameter with the type of one of the multiple type parameters. If one of the multiple types matches the type of the single type parameter, you could merge those. If a matching type is not found, you could add the parameter with the single type as another option in the multiple type parameter.

Similarly, if the overriding parameter is the multiple type one, do you completely replace the other parameter, or do you try to find a matching type in the type choices, merge them if found, and otherwise add it as a choice otherwise?


#3

Overriding should be the way to go… there is a current bug I reported about something related to this, check http://forums.raml.org/t/overwriting-traits/497

The thumb rule should be that implicit properties override explicit (inherited from traits) ones. Or thats my opinion :), completely replacing them NOT merging it. This should be at least for queryparameters, headers, responses, security, body (post…)…