GSoD 2020 - OpenMRS REST API Documentation

ok @ayesh I will just add one basic auth example in that section and leave the jsession token part for now !!

@ayesh I need some help in the last section of the auth resource in this PR could you look at my comments :slight_smile:

1 Like

hi @ayesh do you have some time to help me look through this task on the trello board https://trello.com/c/m6LOgm64/19-update-our-old-rest-wiki-pages-to-point-to-the-new-rest-documentation cc @burke

he has done it already @herbert24 for my current trello tasks !! :slight_smile:

Hi @saurabh

I merged youre pr.Now lets focus on what @burke mentioned.I saw u have created a draft pr for concept.Looks good.

Can we find few talk posts where developers or new comers found problematic to use the authentication in openmrs ? As a start point ?

2 Likes

Actually @ayesh I have made a list of those talk posts and I am going to remove all those issues in the 3 resources that burke pointed out.

I am done with authentication and currently working on concept section . also I am trying to encorporate all those changes which burke deemed as minimum requirement for each resource here

after I am happy with the current state of these three resouces then we can have a reveiw or a survey again of these theree resources while in parallel I will continue working on other resources and get back to these resources after getting feedback from people

Great man.Please share the links in the thread so we can get @burkes opinion as well.

Good work done so far keep it up

1 Like

sure @ayesh I will be linking all my PRs here and in trello as I am doing :+1:

hi @ayesh can we create a concept class type with same name but different description (I tried It throws a error 400 bad request status code), similarly can we create a concept class type with different name but same description ?

I would expect concept class name to be unique. Identical descriptions would be unusual & bad practice, but not prevented.

2 Likes

thanks @burke

@ayesh what are the full specs needed for a password while updating It. I figured out you need atleast one integer in the password to make it valid are there some other rules as well?

See Security settings in the Legacy UI. There are several options, including a regex option. I believe the default is at least 8 chars with at least one number and both upper & lower case letters. So, you could suggest these requirements or those set by the system administrator.

1 Like

@ayesh @burke @gcliff

  1. what is context of this uniqueId for concept-source, Is it same as UUID for other sources? if its the UUID then I think while creating a concept source we shouldnt pass this as an argument rather it will be assigned by demo server?

  2. Are these concept-source resources read-only since I got this error while purging operation for one of those resources

  3. Does concept-Attribute Type subresources also requires some special priviledges to create, I am not able to create any instance of this resource. I am also getting a empty result on fetching all the concept attribute type subresource.

I think its not the UUID of the concept-source resource I saw the returned JSON response, it has a UUID already. so what is this field used for?

It would be nice to have the canonical URL for a source here (e.g., the official url for LOINC). The only example I could find was here where it was used for an OID. I would assume a canonical URL or OID would be fine here, aligning with FHIR’s CodeSystem.url.

The error you got was a constraint violation, meaning you were trying to remove something from the database that is referenced elsewhere. In this case, there are probably existing reference terms in the database referring to the concept source, so you cannot delete it from the database.

You should be able to do this as admin. Your difficulty is probably either from the complexity of correctly defining an attribute type in JSON or that the feature is not fully implemented.

1 Like

Thanks @burke.

I got an empty response upon retriving all the concept attribute type, is it allright or something bad happened with my API call to demo server https://demo.openmrs.org/openmrs/ws/rest/v1/conceptattributetype?

Given there are no concept attribute types on the demo server:

I would expect an empty list when querying via the REST API:

$ http -a admin:Admin123 -b \
    https://demo.openmrs.org/openmrs/ws/rest/v1/conceptattributetype
{
    "results": []
}

Once you create a concept attribute type on the demo server:

you can see it via the REST API:

$ http -a admin:Admin123 -b \
    https://demo.openmrs.org/openmrs/ws/rest/v1/conceptattributetype
{
    "results": [
        {
            "display": "Foobar",
            "links": [
                {
                    "rel": "self",
                    "uri": "http://demo.openmrs.org/openmrs/ws/rest/v1/conceptattributetype/10db69d5-a9fc-4bc6-ae08-565a96f8cd4d"
                }
            ],
            "uuid": "10db69d5-a9fc-4bc6-ae08-565a96f8cd4d"
        }
    ]
}
1 Like

Hi @saurabh

Small info for you. If you don’t get any response for a resource like conceptattribute or any other resource. Please first go to the reference application because all resources related to openMRS and values are presented in the reference app. And if there are no values there add one and try again :slightly_smiling_face:.

1 Like

yes @ayesh I will do this from now onwards .