Sorry, I should have read the whole thread first, I didn't notice you
want to generate the client from an OpenAPI spec.

On 5/29/20 9:40 PM, Stefan Seelmann wrote:
> On 5/28/20 11:57 PM, Ash Berlin-Taylor wrote:
>> Hi everyone,
>>
>> We're really close to getting the OpenAPI spec merged, just one last
>> question that's come up around how we should handle/represent
>> dagrun.conf to triggerDagRun.
>>
>> Which of the these two do people prefer?
>>
>>
>> POST /api/v1/dags/{dag_id}/dagRuns/{dag_run_id}
>> Content-Type: application/json
>>
>> {
>>   "dag_run_id": "manual_2020-05-28T21:42:36Z",
>>   "execution_date": "2020-05-28T21:42:36Z",
>>   "conf": "{\"key\": \"value\" }"
>> }
>>
>> OR
>>
>>
>> POST /api/v1/dags/{dag_id}/dagRuns/{dag_run_id}
>> Content-Type: application/json
>>
>> {
>>   "dag_run_id": "manual_2020-05-28T21:42:36Z",
>>   "execution_date": "2020-05-28T21:42:36Z",
>>   "conf": {"key": "value"}
>> }
>>
>> i.e. should the schema/type of conf be a (JSON-encoded) string, or an object.
>>
>> I favour the later, Kamil the former. His point is that staticly typed
>> languages, and Java in particular, would be hard to represent this.
>> (Please correct me if I've over-simplified or misunderstood your
>> argument Kamil)
> 
> If your concern is Java I can ensure it's possible to deal with the 2nd
> approach, even with arbitrary complex conf. Not as short and elegant as
> with Python, but doable ;). I worked with both Gson and Jackson those
> support it. I'll create an example...
> 
> Kind Regards,
> Stefan
> 

Reply via email to