Resources without representation (REST WS)

Development
1

Some resources (encounter type, order type, concept class …) do not have a representation. The getRepresentationDescription method returns null. This means that the order of attributes in the JSON output will be random. Is this the expected behaviour? Or would it be better to build a DelegatingResourceDescription object like the rest of resources?

2

Quickly searching I see

Haven’t looked for the others. But if any are missing, yes, we should create explicit resources for them.

3

You mean create explicit representation descriptions right?

4

Sorry, I misread you.

Is the order really random if the description method returns null? Or does some superclass provide standard consistent behavior for metadata classes?

If it’s random, then yes, we ought to make it deterministic. I would prefer that by adding default behavior in a superclass.

5

If there is no representation description the order of setter execution is determined by the JSON submitted. After fixing https://issues.openmrs.org/browse/RESTWS-483 subresources behave like normal resources except when there is no representation, in this case it uses JSON order. The base class does not provide a default representation (its an abstract method). Currently I take care of the representation being null, but another option is to provided representations for all resources.

6

@lluismf

I finally had time to look at the code.

Would this problem be fixed if we add a base implementation of getUpdatableProperties() to match the one for getCreatableProperties() here

?

(Even if that doesn’t fix it all by itself, my general suggestion is that since these metadata resources that you have pointed out are inheriting some default behavior, so we should have that same default behavior power the property update order, if possible.)

7

It’s not about creating or updating resources, in this case it was a GET operation. It’s already fixed, but I think it’s better if every resources declare explicitly the order of attributes of representations.

MetadataDelegatingCrudResource could provide a default implementation of getRepresentationDescription based on common metadata attributes but child classes should add the rest of attributes.

In OrderTypeResource the method is misleading because there is no implementation in the parent class:

@Override
public DelegatingResourceDescription getRepresentationDescription(Representation rep) {
	// use the defaults for metadata from the parent class
	return null;
}

But it’s not really that important, we can leave it as is. It’s more about homogeneity than other reason.

8

I’m hoping that we can avoid explicitly defining these for any metadata class that only has uuid, name, and description. I agree that anything with more properties should be defining the behavior itself.

That said, if there are only a couple of resources (like EncounterType) that have this default behavior, and the other 90% of resources have specific behavior, then I’d be fine if you want to explicitly fill in the 10% even if this isn’t necessary.

Ideally people aren’t having to go to the code to see what properties a resource has, and in what order, but this can come from the documentation!

9