Showing results for 
Show  only  | Search instead for 
Did you mean: 

How best to model REST API and their ressources


How best to model REST API and their ressources


We are currently looking at how best to model REST type API and their ressources with MEGA Hopex. Has anyone already "been there, done that", and if so, how did you go about it ? We are thinking of using the Application Service object and adding a stereotype "API". These could then be attached to Application (user and owner). We consider using our Entity(MD) from our data models as ressources. The link between the two doesn't exist in the standard meta-model, so maybe not the best idea ?

All feedback would be greatly appreciated.


3 Replies



>We are thinking of using the Application Service object and adding a stereotype "API".


Well, this a hack when using HOPEX without the SOIA module.
The "Application Service" concept aims at representing an internal component of an application. In moderm application architectures, this could be a servlet, a java class or a .NET Class, considered from a functional viewpoint, without their technical details. In mainframe application architectures, an "Application Service" would be the functional view of a batch program or a COBOL program.
As, by definition, an API is the external part of an application, "Application Service" is not the appropritate candidate.


During the last decade, HOPEX has integrated a new set of concepts aiming at representing APIs. These are the Exchange Contact/Exchange concepts along with their exposure withi applications structures:  service points and request points. They provide a flow based approach for APIs. This approach also fits with the flow based approach taken by BPMN and HOPEX.
Following that route, it is even possible to produce swagger like documentation, directly from HOPEX models (see attached document).


However, there is a challenge in transitionning from traditionnal application architecture thinking to modern modular architecture principles.
MEGA is providing a training along with the SOAI module to gather those principles. We warmly recommand that you follow it.



Thanks for your reply, and the interesting document attached. All we really want to do is to have an available list of publised APIs with a certain amount of information (exposure, protocols used, business function supplied...) and the ressources they use. I'm not sure about using the notion of UML CLASS to define the ressources, any ideas on that ?




Hi, excelent information, but I have some doubts yet, ¿we need SOIA module or just using Application Technical Architecture diagrams is enough?, what about microservices architecture? is there a best practice describing how to model API's, define a microservice catalog?, json and Swagger modeling and documenting?, thanks for any advise.