REST for subclasses of classes which already are resources

Tags: #<Tag:0x00007f01bf860c50>

Dear @wyclif thanks for pointing me to this!

are there any wiki resources on this topic?

how can I access TestOrder via REST since it is not a Resource (dont see it in the swagger UI and also if I try to GET an existing TestOrder via ws/rest/v1/testorder/ddbcd130-edbc-451a-9153-a049b0a0caa5)?

It used to be in the Swagger docs - I’m not sure why I can’t find it now. It might also depend on what version you’re using, because I think some changes have been made to orders in the latest version of the platform.

If you’re doing a search you should be able to do something like:

GET /ws/rest/v1/order?type=testorder

To access it directly, I think you just get it directly from the order resource:

GET /ws/rest/v1/order/ddbcd130-edbc-451a-9153-a049b0a0caa5

Disclaimer: I’ve never used this resource, so I could be wrong :slight_smile:.

With get operations, i believe the request parameter should be ‘t’ and not ‘type’, type is used with post and should be in the posted json content and not a request parameter, therefore to fetch or search test orders, the REST end point should be:

GET /ws/rest/v1/order?t=testorder

Aha :slight_smile:

and what about the RadiologySearchHandler I wrote, am I still able to use it and if so how (since the handler was written for a Resource that doesnt exist anymore)? For example I have request param “patient” is

GET /ws/rest/v1/order?t=testorder

than served by my SearchHandler?

Do you mean SearchHandler or SubclassHandler for Radiology?

I mean SearchHandler, as I said I have written a SearchHandler for the RadiologyOrderResource which provides several query params for the RadiologyOrderResource. Now if the RadiologyOrderResource no longer exists since I should make a RadiologyOrderSubclasshandler what happens with the RadiologyOrderSearchHandler? I still want to provide the same query params

Any advice on how to add functionality provided by a custom SearchHandler to RadiologyOrderSubclasshandler ?

A search handler can be written for virtually anything, so you probably don’t have to change your search handler

I am sure I have to change something. If the RadiologyOrder Resource doesnt exist then I guess the SearchConfig cannot point to “radiologyOrder”, should probably be “order” then. But I only want to provide the SearchHandler for RadiologyOrders so do I need to add the type parameter to withRequiredParameters ? And if so how do I ensure that the type parameter values are only “radiologyorder”?

I recall mentioning that get operations for resources with subclasses should typically have the t request parameter, use its value to restrict to radiology orders in your search handler

Hi :slight_smile:

The problem I faced when restricting the search handler to radiology orders is that on every order search the search method of the new order search handler gets called and not the doSearch of the order resource.

Is it a good idea to create a RadiologyOrderResource and a RadiologyOrderSubclassHandler, so we can provide radiology order as subclass to the order resource and implement RadiologyOrderSearchHandler on top of our radiology order resource?

Dear @pascal and @wyclif as Dominik pointed out our solution would be to have a RadiologyOrderSubclassHandler as you guys suggested but still have a RadiologyOrderResource which basically just delegates operations to the RadiologyOrderSubclassHandler but enables us to have a RadiologyOrderSearchHandler which does not interfere with the OrderResource and potential SearchHandlers of it.

Is this approach sound in your opinion?

I’m actually not entirely sure what the best approach is here. This is something we haven’t seen before and it might require some discussion on a design call.

At the very least we need to hear what @raff, @darius and @wyclif think.

The only opinion I have right now is that it doesn’t seem right that a module should intercept searches for core resources, so I’d go with your second option. But I would definitely wait to hear from the experts.

dear @raff @darius and @wyclif I know you get a lot of posts directed to you, but we are blocked on this issue for quite a while now and have tried and laid out all kinds of ways on how to solve this issue. it would be of great help to us if we could get some advice from you. thanks a lot!!

I just skimmed the thread. Do I understand correctly that you just need a search handler, which is capable of finding an order of the radiology type for the given patient?

If yes, then how about you create OrderRadiologySearchHandler with the following config:

new SearchConfig("default", RestConstants.VERSION_1 + "/order", 
    Arrays.asList("1.11.*", "1.12.*", "2.0.*"),
    Arrays.asList(new SearchQuery.Builder("Allows you to find radiology orders by patient").withRequiredParameters("radiology", "patient").build())
);

The “radiology” parameter could have any value, but “true” would make most sense.

Or did you try that approach already?

If you have a bit more spare dev time it would be great to introduce a new

withRequiredParameters(new SearchParameter("type", "radiology"), new SearchParameter("patient"))

to SearchQuery and add support for that in RestService.getSearchHandler. Basically match a handler not only by parameter, but also by its value.

If you decide to go with the latter and contribute to webservices.rest please do create an issue and point me to it. We’ll fast-track it and release ASAP in return :slight_smile:

@teleivo, one approach would be to schedule this to discuss on a design call. Then at least you’re guaranteed an hour of attention. :slight_smile:

thank you guys @raff and @darius I think a design call would be best. Ill apply for one in September as I am taking a break :slight_smile:

RadiologyOrder should have a subclass hander and not its own resource, and the same should be done for other sub classes you add

We’ve explained why it is not as simple as that in our case where we need a SearchHandler for our Subclass and do not want to affect any other SesrchHandler’s of other Subclasses of the same parent. I’ll present this on a design forum where there is more time and direct communication.

You might as well have the search logic inside the subclass handler, it isn’t a must to have it in a separate SearchHandler