GSoC 2018-HTML Form Entry Module and REST

@ivange94 Thank you very much for your support.

@ivange94 Thanks a lot, the link is very useful.

Thanks, I’ve sent an email invite to join as mentor.


@owais.hussain @ivange94 I have been trying to get familiar with the source code and their basic operations. I ran to the following method which returns a JSP.

What I think is that this method is already a part of REST API(please correct me if I am wrong). There are lots of such methods. How should these methods need to be changed to meet the desired REST API standards ?. Feel free to enlighten me on this. Thanks

So what you are looking at is a controller that handles request from the UI and returns a view. OpenMRS uses the MVC pattern. That is not a REST API. What is happening there is a user will make a request with their browser by visiting a link and depending on the link that they click a controller method will be called. Within this controller method if we need access to OpenMRS data, we use the Java API here like you see in the first two lines of the of that method. And after processing a view(JSP) will be returned.

What you are asked to build is to be able to post and fetch html forms via REST. Your request body will be a JSON and the response is also JSON.


@ivange94 Thanks, so this particular method should be able to be called directly by the user(through a REST POST call) and this method should be self-sufficient to return a html back ?

@owais.hussain @ivange94 Is Spring Boot a possible option in building our REST controllers ? I guess it is a widely used framework for REST API. :slight_smile:

@madushan try building and deploying and openmrs module to have a feel of what you’ll be doing. We may create a new project for this or just add this functionality to the existing html form entry module. IMO that’s not important now. What I’d love to see in your proposals is how you plan to solve this problem.

About using spring boot, I think to introduce spring boot it has to start from core as modules themselves are not full web applications as other spring projects. They are just openmrs modules. You can’t deploy them as normal web applications. It’s openmrs-core that is a web application. That been said, which technology to use is not very important now. What’s more important is how you plan to solve the problem.

1 Like

Also you are required to make prior contributions to OpenMRS before you submit your proposal. This tells us about your skill level and how committed you are. A proposal without any contribution will not be looked at. Go to and pick issues there to work on. If you can pick issues from the html form entry module itself, that will be great. But any non trivial issue should be able to tell us if you are capable of the job.


@ivange94 Thank you very much for your guidance. They are of great value. I have been working with a Swagger integrated sample Spring server to demo the functionality of REST API . I will try creating a openmrs module and on JIRA issues as well.

1 Like

I think @ivange94 has already replied in detail.


@owais.hussain Yes he has given a good clarification. Thanks for your support too.

1 Like

@owais.hussain @ivange94 The REST Api should take security into account as well. Should we include the actions to enhance security in our proposals ?

@michael25 what kind of security are you referring to, apart from Authentication. Can you please elaborate?

1 Like

@owais.hussain I was referring to the user authentication too. Should the users of the REST API have a separate authentication to that of the users of the web app? And one more thing :slight_smile: , when making new html form entry, in the REST Api, can we implement user sending the html form as a String embedded in a JSON ?

@michael25 I can’t seem to make any scenario where one would need separate authentication. If say, there’s a web app that uses REST API, the security management of the users of this particular web app should be handled via core REST resources, rather than going through HFE REST resources. Or maybe I misunderstood your point.

Secondly, why not? It will enable the end-developer to submit any form. The big question is that can we create a function to correctly parse any HTML form in our controller?

1 Like

@owais.hussain @ivange94 Thank you very much. I think I got my answer for authentication requirement :slight_smile: In HTML Form entry, the HFE module currently submits the Html Form as a text. So In the REST scenario, the same text could be sent in a JSON and the controllers would not have to be modified largely ? But I find it difficult on planning how to submit the forms with values. Feel free to guide me.

@owais.hussain, i think what @michael25 has assumed is these endpoints are openly accessible(which might not be wrong). What all of us here are assuming is this REST endpoints will be accessed by the POC inside the OpenMRS RA or any openmrs UI(after we login), which is debatable and is a choice by design. there could be two possibilities:

  1. The design could allow the REST endpoints to be accessible via the Openmrs UI only after login so that authentication is taken care of already.
  2. OR The endpoints are independently accessible without login (here the authentication has to be taken care of somehow).

@ivange94, this would be very helpful. Can you please schedule this in the upcoming OpenMRS University meeting. Thanks.

1 Like

Thanks @piyush9620 I see your point. I haven’t used the first approach particularly with REST. With Basic authentication, it is simpler to repeatedly attach username and password… basically keeping the communication stateless. However, the first approach is how OAuth works. I think it would be a good idea to take that approach.

But we should discuss this in next University meeting.