OHDSI Home | Forums | Wiki | Github

Proposed WebAPI Structure

Developers
#1

As was discussed yesterday on the architecture call I’m proposing the following structure for comment and discussion.

To be clear, the following format is describing our proposed package organization (namespaces) where classes would sit and sample routes that would live in each of the services. The overall project namespace (org.ohdsi.webapi) would contain sub-packages for models relevant to each separate service. The service sub-package would contain all classes that expose routes.

We’ll be keeping this open for discussion for the next week before finalizing for the initial WebAPI project release.

org.ohdsi.webapi (namespace)

.cohort (namespace)
	CohortDefinition (class)
	PersonCriteria (class)

.service (namespace)
	VocabularyService (class)
		/webapi/vocabulary/concept/5 (sample GET route)
	CohortService (class)
		/webapi/cohort/generateSql (sample POST route)
	MethodService (class)
		/webapi/method/ccd (sample POST route)
	KnowledgeBaseService (class)
		/webapi/knowledgebase/knowledge/5 (sample GET route)

.vocabulary (namespace)
	Concept (class)
	ConceptRelationship (class)
#2

On 12/05/2014 11:38 AM, Frank DeFalco wrote:

	KnowledgeBaseService (class)
		/webapi/knowledgebase/knowledge/5 (sample GET route)
I am wondering if we should plan for the knowledgebase namespace to have at least a couple of sub-project calls. Since LAERTES is really an evidence base that will be used to build a "reference standard" , perhaps this will make sense: 
	KnowledgeBaseService (class)
		/webapi/knowledgebase/laertes/...
then we can add another path for whatever we call the reference standard . 'Get' should be sufficient for most API calls but the drill down use case will probably need Post at some point. I think its easy to do both right?
#3

I have no objections to a sub-route however @jon_duke had made the recommendation that we try and be more descriptive in our approach. Instead of using our greek project names, describing what the features are providing. That’s why we went with /vocabulary instead of /hermes.

#4

Yes as @Frank said, I am encouraging our API naming to be friendly even for those less versed in Greek mythology. So @rkboyce, I would use ‘evidence’ or something along those lines rather than laertes in the naming of the API. Laertes would be one of many applications using this API (we hope).

Also, Frank, I reviewed the namespaces with my team and got a thumbs up all around so no concerns from here.

Jon

t