On Fri, May 29, 2020 at 9:28 PM QP Hou <q...@scribd.com> wrote:
>
> On Fri, May 29, 2020 at 7:18 AM Kamil Breguła <kamil.breg...@polidea.com>
> wrote:
> > I have the biggest concerns about reading data, not about sending data
> > so in my opinion we should think about how we want the response from
> > the server to look like?
> >
> > GET //dags/{DAG_ID}/dagRuns/
> >
> > {
> > "dag_runs": [
> > {"conf": {"A":"B"}}
> > {"conf": {"C":"D"}}
> > ]
> > }
> >
> > or
> > "dag_runs": [
> > {"conf": "{\"A\":\"B\"}}
> > {"conf": "{\"C\":\"D\"}}
> > ]
> > }
> >
> > If we choose one output format, we can think about whether we want to
> > make changes to this object structure so that the input object does
> > not match the output object. In my opinion, this is not a good idea.
> > REST is based on resources/types that have a unified interface and
> > fields that are ambiguous can be problematic for users.
>
> Again, back to my previous comment, I feel like by encoding it as a
> string, we are just pushing this problem to a different part of the
> code base. The user still needs to serialize that string into a
> generically typed object in order to use it. If the user doesn't need
> to read/use conf attribute, then I think it doesn't matter if it is a
> string or generic object or not, it will just be passed along as is.
>
We move the problem to a place where we have enough data to handle it.
The user has information about whether he can indicate a better type
based on many parameters e.g. dag_id or execution_date. I imagine that
the user may want to convert the conf to type field depending on
dag_id and choose the solution that best suits his situation.
https://pastebin.com/UpUKYEvg
It is the user who specified the input data (e.g. in Web UI), so the
user can best choose how to process this data.
