REST API with several entities

REST API with several entities

  

Hi 

is it possible to create a REST service in OS with actions for several entities?

http://..../Project/Entiy1/Update

http://..../Project/Entiy2/Update

without having to create this for every entity. So if an antity is added to the db, the REST service will also work with the new entity (without changing the REST service)

http://..../Project/EntiyNew/Update

NB entities can have different structures. We build such a service in.Net, but I'm curious if you could do this in OS (and how)? 

Regards, Harry

 


More information:we used a .NET lib for that: https://github.com/markrendle/Simple.Data

Hello Harry,

The only way I see that maybe would be possible to do this in OutSystems is to parse the request body (with the information) in the Action that is being executed by the request, and change the information to be set in a "default" structure (manipulating the JSON of the request).

Than you could use this information in a probably very complex SQL to insert/update/etc information in your entity.

As the System would not know about the entity itself (I'm assuming here that you want to avoid having to do changes in the application that contains the rest service), you would have to use some very unsafe and "should be avoided at all costs" methods to be able to access the database tables.

BUT...

As "new entities" mean that the business logic is changing (with new features or changes in existing features), what is the problem in add new methods to the REST service also? It is not as the REST service itself were a very complex logic to deal with (they shouldn't be anyway) and you should separate business logic from integration anyway.

While you could gain some "agility" not having to add specific code to the integration, in the long run this would become more and more error prone and less maintainable...

So, what is the idea?

Cheers,
Eduardo Jauch

Hi Eduardo,

Our business (contact center) is very rapidly changing. New contactlists are loaded in a dialer and in our application (callscripts) we make REST calls with the name of the contactlist (and there are a lot of them). So speed was the issue here to be able to deliver fast. Instead of every time creating a REST service (or adding methods) we decided to use a generic approach. No matter what entities, the REST API  need not change.  I dont know if this way is unsafe; we secured it with security groups on AD level and built that in our API. So, there you have the idea behind it.

Regards, Harry.