How to extend web services

classic Classic list List threaded Threaded
4 messages Options
Friedman, Roger (CDC/CGH/DGHA) (CTR) Friedman, Roger (CDC/CGH/DGHA) (CTR)
Reply | Threaded
Open this post in threaded view
|

How to extend web services

    JSS Raxa is about to go into a big front-end development phase.  During this time, it is liable to need REST interfaces with some tables which have not yet been carried forward in the REST module or in the module which defines them, and certainly some custom queries and/or representations.  It will need these on a schedule which fits into its front-end development pace.  I anticipate that JSS Raxa will build a helper module to contain those elements which don't exist in OpenMRS.

     What I'd like to discuss is how this work should be coordinated with OpenMRS.  Should we create OpenMRS tickets for all this work? for work that we think should be incorporated into OpenMRS? for none of this work?  Is there a release schedule with which we can coordinate?  Would you rather that the helper module have its own pseudo-resource or that it extend and override resources using the @Handler order parameter?

    Any thoughts or suggestions would be appreciated.  @Jeremy, did you encounter any similar issues using REST?


[hidden email] from OpenMRS Developers' mailing list
Burke Mamlin Burke Mamlin
Reply | Threaded
Open this post in threaded view
|

Re: How to extend web services

Tickets for changes/bugs around RESTWS would go into that project.  If they are working on a module in our repo and have a project for it in JIRA, then tickets relevant to that module would go into that JIRA project.  If there are tickets that are for an application that is separate from OpenMRS, then those should go into the ticketing tool for that application.

Ideally, any needs for extending existing functionality using the same pattern would go into RESTWS.  Those features require some design discussion (e.g., add features that break the pattern or start new conventions) can still go into RESTWS when vetted and, if we decide against them or the timing isn't fast enough for your needs, can be managed within your own module.  You can create methods temporarily in your own module and then turn them into pass-throughs or eliminate them when/if that functionality is added to RESTWS.

In the end, the more we can converge on getting basic functionality robust within RESTWS, the better for all (and the less code you'll be left maintaining on your own).

-Burke

On Wed, May 2, 2012 at 8:36 AM, Friedman, Roger (CDC/CGH/DGHA) (CTR) <[hidden email]> wrote:

    JSS Raxa is about to go into a big front-end development phase.  During this time, it is liable to need REST interfaces with some tables which have not yet been carried forward in the REST module or in the module which defines them, and certainly some custom queries and/or representations.  It will need these on a schedule which fits into its front-end development pace.  I anticipate that JSS Raxa will build a helper module to contain those elements which don't exist in OpenMRS.

     What I'd like to discuss is how this work should be coordinated with OpenMRS.  Should we create OpenMRS tickets for all this work? for work that we think should be incorporated into OpenMRS? for none of this work?  Is there a release schedule with which we can coordinate?  Would you rather that the helper module have its own pseudo-resource or that it extend and override resources using the @Handler order parameter?

    Any thoughts or suggestions would be appreciated.  @Jeremy, did you encounter any similar issues using REST?


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list
Friedman, Roger (CDC/CGH/DGHA) (CTR) Friedman, Roger (CDC/CGH/DGHA) (CTR)
Reply | Threaded
Open this post in threaded view
|

Re: How to extend web services

Burke, I envision few if any changes to the basic paradigm.  I think the JSS-motivated tickets will go into the JSS JIRA, likewise the code into the JSS repo.  But suppose we're going to do a custom search with general utility, such as search for locations with a specified location tag (ws/location?tag=foobar), or a search for patients with addresses in a certain geography (ws/patient?address=province:Indiana); do we put this in the OpenMRS JIRA when we envision it as a marker to the world, or wait until after we've implemented it and add it along with a patch?

 

The most off-paradigm thing I see coming down the pike has to do with reporting.  Like the old BIRT and Jasper report modules (I need to review and coordinate with the new GSOC project around this), there will probably be report and parameter tables.  These tables need to be extended to the REST API for report selection and parameter entry.  Then we will need some sort of function to receive the report name and parameter values and return the path of the generated pdf file (or error status).  Maybe this becomes a PUT function, I haven't given it much thought.

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Burke Mamlin
Sent: Wednesday, May 02, 2012 9:41 AM
To: [hidden email]
Subject: Re: [OPENMRS-DEV] How to extend web services

 

Tickets for changes/bugs around RESTWS would go into that project.  If they are working on a module in our repo and have a project for it in JIRA, then tickets relevant to that module would go into that JIRA project.  If there are tickets that are for an application that is separate from OpenMRS, then those should go into the ticketing tool for that application.

 

Ideally, any needs for extending existing functionality using the same pattern would go into RESTWS.  Those features require some design discussion (e.g., add features that break the pattern or start new conventions) can still go into RESTWS when vetted and, if we decide against them or the timing isn't fast enough for your needs, can be managed within your own module.  You can create methods temporarily in your own module and then turn them into pass-throughs or eliminate them when/if that functionality is added to RESTWS.

 

In the end, the more we can converge on getting basic functionality robust within RESTWS, the better for all (and the less code you'll be left maintaining on your own).

 

-Burke

 

On Wed, May 2, 2012 at 8:36 AM, Friedman, Roger (CDC/CGH/DGHA) (CTR) <[hidden email]> wrote:

    JSS Raxa is about to go into a big front-end development phase.  During this time, it is liable to need REST interfaces with some tables which have not yet been carried forward in the REST module or in the module which defines them, and certainly some custom queries and/or representations.  It will need these on a schedule which fits into its front-end development pace.  I anticipate that JSS Raxa will build a helper module to contain those elements which don't exist in OpenMRS.

     What I'd like to discuss is how this work should be coordinated with OpenMRS.  Should we create OpenMRS tickets for all this work? for work that we think should be incorporated into OpenMRS? for none of this work?  Is there a release schedule with which we can coordinate?  Would you rather that the helper module have its own pseudo-resource or that it extend and override resources using the @Handler order parameter?

    Any thoughts or suggestions would be appreciated.  @Jeremy, did you encounter any similar issues using REST?


[hidden email] from OpenMRS Developers' mailing list

 


[hidden email] from OpenMRS Developers' mailing list

Darius Jazayeri-3 Darius Jazayeri-3
Reply | Threaded
Open this post in threaded view
|

Re: How to extend web services

@Roger, I think that JSS should manage the tickets however is most convenient for its development purposes. We'd love to get examples like the ones you gave committed to the core RESTWS module, but it's fine if those happen via by creating a ticket+patch for something JSS already did in its own issue tracker. Whatever works.

Regarding reporting, by the way there's a reportingrest module that lets you run reports via rest and get datasets as json. It's preliminary (might not support parameters yet, I forget), but that seems like the place to support running reports and getting back their rendered output.

-Darius

On Wed, May 2, 2012 at 7:34 AM, Friedman, Roger (CDC/CGH/DGHA) (CTR) <[hidden email]> wrote:

Burke, I envision few if any changes to the basic paradigm.  I think the JSS-motivated tickets will go into the JSS JIRA, likewise the code into the JSS repo.  But suppose we're going to do a custom search with general utility, such as search for locations with a specified location tag (ws/location?tag=foobar), or a search for patients with addresses in a certain geography (ws/patient?address=province:Indiana); do we put this in the OpenMRS JIRA when we envision it as a marker to the world, or wait until after we've implemented it and add it along with a patch?

 

The most off-paradigm thing I see coming down the pike has to do with reporting.  Like the old BIRT and Jasper report modules (I need to review and coordinate with the new GSOC project around this), there will probably be report and parameter tables.  These tables need to be extended to the REST API for report selection and parameter entry.  Then we will need some sort of function to receive the report name and parameter values and return the path of the generated pdf file (or error status).  Maybe this becomes a PUT function, I haven't given it much thought.

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Burke Mamlin
Sent: Wednesday, May 02, 2012 9:41 AM
To: [hidden email]
Subject: Re: [OPENMRS-DEV] How to extend web services

 

Tickets for changes/bugs around RESTWS would go into that project.  If they are working on a module in our repo and have a project for it in JIRA, then tickets relevant to that module would go into that JIRA project.  If there are tickets that are for an application that is separate from OpenMRS, then those should go into the ticketing tool for that application.

 

Ideally, any needs for extending existing functionality using the same pattern would go into RESTWS.  Those features require some design discussion (e.g., add features that break the pattern or start new conventions) can still go into RESTWS when vetted and, if we decide against them or the timing isn't fast enough for your needs, can be managed within your own module.  You can create methods temporarily in your own module and then turn them into pass-throughs or eliminate them when/if that functionality is added to RESTWS.

 

In the end, the more we can converge on getting basic functionality robust within RESTWS, the better for all (and the less code you'll be left maintaining on your own).

 

-Burke

 

On Wed, May 2, 2012 at 8:36 AM, Friedman, Roger (CDC/CGH/DGHA) (CTR) <[hidden email]> wrote:

    JSS Raxa is about to go into a big front-end development phase.  During this time, it is liable to need REST interfaces with some tables which have not yet been carried forward in the REST module or in the module which defines them, and certainly some custom queries and/or representations.  It will need these on a schedule which fits into its front-end development pace.  I anticipate that JSS Raxa will build a helper module to contain those elements which don't exist in OpenMRS.

     What I'd like to discuss is how this work should be coordinated with OpenMRS.  Should we create OpenMRS tickets for all this work? for work that we think should be incorporated into OpenMRS? for none of this work?  Is there a release schedule with which we can coordinate?  Would you rather that the helper module have its own pseudo-resource or that it extend and override resources using the @Handler order parameter?

    Any thoughts or suggestions would be appreciated.  @Jeremy, did you encounter any similar issues using REST?


[hidden email] from OpenMRS Developers' mailing list

 


[hidden email] from OpenMRS Developers' mailing list



[hidden email] from OpenMRS Developers' mailing list