(01:36:04 PM) mcimbora: ge0ffrey: I'm working on the REST interface and this is a current state where ServiceResponse wrapper has been removed 
(01:36:11 PM) mcimbora: I've got a couple of concerns though
(01:38:03 PM) mcimbora: The interface is a bit clumsy to use, e.g. to submit a planning problem, you need to invoke updateSolverState, where you pass updated SolverInstance object with a planning solution set & updated solver status to SOLVING 
(01:38:38 PM) mcimbora: Similarly, when you want to stop the solver, you need to call updateSolverState with solver status set to TERMINATE_EARLY
(01:38:53 PM) ge0ffrey: yes, that's a typical REST approach
(01:38:57 PM) mcimbora: I am thinking about introducing separate methods for that
(01:39:12 PM) mcimbora: & getting rid of the status completely
(01:39:18 PM) ge0ffrey: (Edson explained this to me, I am not a big fan myself, but it seems to follow REST guidelines)
(01:39:38 PM) ge0ffrey: triceo: ^
(01:39:52 PM) mcimbora: Aha, to me it's more logical to call submitSolution(solution, solverId), which sets the status to SOLVING internally
(01:40:48 PM) ge0ffrey: mcimbora: I felt (feel?) the same way, but apparently REST guidelines would rather see a state field instead of these separate service methods
(01:41:27 PM) ge0ffrey: mcimbora: I am not convinced though that we shouldn't switch to submitSolution though, we need more research - let's talk to triceo etc to get more opinions
(01:41:51 PM) triceo: this all sounds very academic to me.
(01:42:00 PM) triceo: what problem are we trying to solve?
(01:42:12 PM) mcimbora: jBPM seems to use similar approach https://github.com/kiegroup/droolsjbpm-integration/blob/master/kie-server-parent/kie-server-remote/kie-server-client/src/main/java/org/kie/server/client/ProcessServicesClient.java
(01:42:28 PM) ge0ffrey: triceo: opttaplanner execution server to solve a use case, let's say employee rostering
(01:42:35 PM) mcimbora: see, startProcess, abortProcessInstance
(01:42:49 PM) ge0ffrey: good point
(01:43:01 PM) ge0ffrey: mcimbora: if jbpm can do it, so can we :)
(01:43:12 PM) ge0ffrey: triceo: so you'd say "be practical, not academic"?
(01:43:20 PM) triceo: ge0ffrey: always :-)
(01:43:26 PM) mcimbora: This is how the interface looks like ATM https://gist.github.com/mcimbora/9ef48f966ffcaa9029b773b410e66742
(01:43:34 PM) ge0ffrey: if we're being practical, then yes, submitSolution() etc is definitly better imo
(01:43:58 PM) ge0ffrey: mcimbora: which of these are GET, POST and PUT?
(01:44:10 PM) ge0ffrey: mcimbora: note the important difference between POST and PUT
(01:44:47 PM) mcimbora: ge0ffrey: See https://github.com/kiegroup/droolsjbpm-integration/blob/master/kie-server-parent/kie-server-remote/kie-server-rest/kie-server-rest-optaplanner/src/main/java/org/kie/server/remote/rest/optaplanner/SolverResource.java
(01:45:09 PM) triceo: REST works on resources. technically, I think you should GET to receive Solver from the main interface.
(01:45:11 PM) triceo: and then GET/PUT/POST/DELETE in the SolverInstance to do whatever you want to the instance.
(01:45:57 PM) triceo: or, in this particular case, the SolveInstance should be it's own endpoint.
(01:46:18 PM) triceo: while other methods, like getSolvers(), should be coming from a different endpoint.