In the past the only endpoints in radiology for RadiologyOrderResource that have always been documented by the REST module are
DELETE /radiologyorder/{uuid}
GET /radiologyorder/{uuid}
GET /radiologyorder
I always assumed that’s because in the RadiologyOrderResource the newDelegate and save methods threw a ResourceDoesNotSupportOperationException and meaning it could not support creation of orders via REST hence the absence for POST documentation for them.
But looks like my assumption was wrong. Because despite the fact that in the RadiologyOrderResource, purge and delete both threw a ResourceDoesNotSupportOperationException, a delete endpoint is still appearing in the REST api documentation. See screenshot below
In an attempt to make the REST module document POST endpoints for RadiologyOrderResource, I changed the implementation of the newDelegate and save methods to
/**
* @see org.openmrs.module.webservices.rest.web.resource.impl.BaseDelegatingResource#newDelegate()
*/
@Override
public RadiologyOrder newDelegate() {
return new RadiologyOrder();
}
/**
* @see org.openmrs.module.webservices.rest.web.resource.impl.DelegatingResourceHandler#save(java.lang.Object)
*/
@Override
public RadiologyOrder save(RadiologyOrder delegate) {
return Context.getService(RadiologyOrderService.class)
.placeRadiologyOrder(delegate)
}
See full RadiologyOrderResource implementation here
But despite doing that I still don’t see any documentation for POST on the REST API docs.
I noticed that the REST module does document POST for RadiologyModalityResource and I the implementation for RadiologyModalityResource is similar to RadiologyOrderResource but for the fact that RadiologyModalityResource is a Subclass of MetadataDelegatingCrudResource while RadiologyOrderResource is a subclass of DataDelegatingCrudResource.
For the post operation to appear, the following conditions should met:
resource need to inherit the method create
and create should not throw ResourceDoesNotSupportOperationException or any other exception when invoked.
See:
But as for delete we only check if the method exists. And don’t seem to handle any exceptions that are thrown when the method is invoked. See:
So for the POST operations to appear you may have to make sure that the create works though I’m not sure how.
FYI:
Schema of the response received from GET /radiologyorder/{uuid} is documented by getRepresentationDescription(). And schema to post RadiologyOrderResource is documented by the method getCreatableProperties()
However those two methods will be deprecated. This is just for your information, so no need defining those.
Thanks this is very great explanation. I’ve learned a lot about the webservices module just from your reply. Wished all this was in the documentation.
However
RadiologyOrderResource does not override this method and yet POST is still documented for it. RadiologyOrderResource does not also override this method but they both inherit this method from DelegatingCrudResource.
This seems to be the difference between the two resources. The RadiologyModalityResource overrides this method but the RadiologyOrderResource does not.
So how do you suggest I proceed now. This is a huge blocker for me.
If its creatable resource (though I’m not sure if it is) you’ll have to make its create method work for it to appear in the doc. BTW I’m not familiar how these create, delegate methods work.
According to the test cases it can’t be deleted or purged either. But they are still documented. If you wonder why, that is to do with the logic I pointed before. There seems to be a problem. So you may open an issue on this
getRepresentationDescription(), and getCreatableProperties() are not mandatory. So discard those.
I’ve changed the implementation of the newDelegate and save methods. They no longer throw ResourceDoesNotSupportOperationException. I’ve just not updated the tests yet.
