[jboss-jira] [JBoss JIRA] (DROOLS-1652) Add an entry point on the kie-server to deploy a DMN files as a service

[Duncan Doyle (JIRA)]

    [ https://issues.jboss.org/browse/DROOLS-1652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13433129#comment-13433129 ] 

Duncan Doyle edited comment on DROOLS-1652 at 7/7/17 4:48 PM:
--------------------------------------------------------------

What should the URL look like in your opinion [~tirelli]? From a RESTful point of view, we're creating a new kie-container resource, so in theory it should be a PUT (create resource) on URL"/server/container/\{id\}" that accepts a DMN file. However, that URL already exist. We could provide support for different request bodies in that operation (e.g. a `KieContainerResource` and a `DmnKieContainerResource`), but that could become a bit nasty ...

We can also use a POST on something like "/server/containers/\{id\}/resources" and have that create a container resource under "/server/containers/\{id\}" (the reason I don't like a PUT in this case is because we create the resource (container) under a different URL than our request URL). The reason for the name "resources" (plural) is that we could provide multiple resources in the body (e.g. multiple DMN files).

Second, apart from the DMN XML file (or files), do we also want to be able to post more information in the body  (e.g. like additional information we pass in `KieContainerResource`)?

And finally, should this be part of the DMN extension or KIE-Server Commons? The argument for DMN would be that otherwise we would expect Commons to have DMN knowledge. On the other hand, it's just deploying a KIE Containerner based on a resource file. The fact that that's a DMN model does not really matter (in theory this could be any resource file). Personally KIE-Server Commons makes most sense.


was (Author: mccloud):
What should the URL look like in your opinion [~tirelli]? From a RESTful point of view, we're creating a new kie-container resource, so in theory it should be a PUT (create resource) on URL"/server/container/\{id\}" that accepts a DMN file. However, that URL already exist. We could provide support for different request bodies in that operation (e.g. a `KieContainerResource` and a `DmnKieContainerResource`), but that could become a bit nasty ...

We can also use a POST on something like "/server/containers/\{id\}/resources" and have that create a container resource under "/server/containers/\{id\}" (the reason I don't like a PUT in this case is because we create the resource (container) under a different URL that our request URL). The reason for the name "resources" (plural) is that we could provide multiple resources in the body (e.g. multiple DMN files).

Second, apart from the DMN XML file (or files), do we also want to be able to post more information in the body  (e.g. like additional information we pass in `KieContainerResource`)?

And finally, should this be part of the DMN extension or KIE-Server Commons? The argument for DMN would be that otherwise we would expect Commons to have DMN knowledge. On the other hand, it's just deploying a KIE Containerner based on a resource file. The fact that that's a DMN model does not really matter (in theory this could be any resource file). Personally KIE-Server Commons makes most sense.

> Add an entry point on the kie-server to deploy a DMN files as a service
> -----------------------------------------------------------------------
>
>                 Key: DROOLS-1652
>                 URL: https://issues.jboss.org/browse/DROOLS-1652
>             Project: Drools
>          Issue Type: Feature Request
>          Components: dmn engine, kie server
>    Affects Versions: 7.1.0.Beta3
>            Reporter: Edson Tirelli
>            Assignee: Duncan Doyle
>
> Add an end point on the kie-server to deploy a DMN xml file directly as a service without the need for a kjar.
> In other words, the end point would accept a POST with a DMN xml file as a payload, it would internally build a kjar in memory and deploy it as a kie-container.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)