[LRUG] API for complex conditional data

Fri Oct 9 01:31:05 PDT 2020

Thanks for the replies and input. I'll try and answer questions below

The current UI persists for each step in the wizard. The overall process
has its own underlying model and each step of the wizard has its own model
which is a sub class of the underlying model and has step specific
validation, controller and views. With the post patch patch... approach we
can reuse these sub classed models creating simple serializers for each one.

I"d expect most clients to use this api by assembling a big chunk of data
from existing systems and using that data to drive the process. I doubt any
of our clients will write their own UI to interact with our API.

The initial version of the API will be a simplified restricted form of the
wizard. Subsequent versions of the API will add additional capability. The
design of the wizard itself is unlikely to change much.

Each wizard step that asks a question deals with one question at time so
the problem of having to deal with multiple responses isn't really there.

Thanks again for your input. Any additional input will be most appreciated

All best

Andrew

On Thu, 8 Oct 2020 at 15:22, Edwin Wills <edwin at rentify.com> wrote:

> An interesting question! I think before I decided on a solution, I'd like
> to understand:
>
> 1) Is the wizard likely to change in any meaningful way in the short-mid
> term - if yes, then I'd try to build something generic, maybe a "questions"
> API that takes attributes to store key/values against specific questions.
> If not, I'd make the API structure match the front end.
>
> 2) How many questions does the wizard show at a time (or is it 1 question
> per step?). If just one question per step, this simplifies the scope a bit,
> as you only ever have to handle one response at a time, and it's easier to
> build something generic. If it's multiple, then I'd refer to my first
> question.
>
> I've built similar APIs using both methods before, and they both have
> their positives and negatives, but ultimately I found that reducing the
> scope to one question submitted/validated at a time, and making the API
> generic really helped to simplify the scope (but I understand you might not
> have the luxury to dictate that!).
>
>
> On Thu, Oct 8, 2020 at 2:20 PM Murray Steele <murray.steele at gmail.com>
> wrote:
>
>> I think my choice would depend on the behaviour of the current UI and the
>> data it stores.
>>
>> If the current UI persists the partial data into your backend, and you
>> actively use and care about that partial data, then I'd want to mimic that
>> in the API - allow for partial submits that are written to the backend so
>> you have parity.  I guess it also depends what the stages of the wizard
>> are, do you want to mimic those exact stages, or just have a POST to
>> create, PATCH to update with any possible attributes and some other
>> endpoint to finalize and submit?
>>
>> If the current UI doesn't store partial data in your backend, or if it
>> does but it's just an implementation detail and you don't care about it,
>> I'd go with the POST only API that requires complete data.  A client of the
>> API can then decide to implement a wizard style UI with partial submits
>> itself using its own store.
>>
>> It comes down to the restrictions you want to set on the clients of the
>> API - a single submit everything API gives them the most freedom I think,
>> but at the cost to you of loss of insight into the partial data.
>>
>> On Thu, 8 Oct 2020 at 11:04, Andrew Premdas <apremdas at gmail.com> wrote:
>>
>>> Hey there,
>>>
>>> We have an application which has a wizard for doing a fairly complex
>>> task (imagine something like a tax form with lots of conditional sections).
>>> We want to create an api to do the same task. We have two approaches under
>>> consideration at the moment
>>>
>>> 1) Mimic the wizard via a POST and a series of PATCH calls
>>> 2) Flatten the wizard into a single POST call
>>>
>>> The first approach would require around 6 calls to complete the task
>>>
>>> The second call would have to fill in 50-60 pieces of data with alot of
>>> different validations and errors. Errors like "You cannot fill in field b
>>> if you have filled in field a"
>>>
>>> My questions for the group?
>>>
>>> Which choice would you make?
>>> Are there alternative approaches to consider
>>>
>>> Thanks for any input/help
>>>
>>> All best
>>>
>>> Andrew
>>>
>>> --
>>> ------------------------
>>> Andrew Premdas
>>> blog.andrew.premdas.org
>>> _______________________________________________
>>> Chat mailing list
>>> Chat at lists.lrug.org
>>> Archives: http://lists.lrug.org/pipermail/chat-lrug.org
>>> Manage your subscription:
>>> http://lists.lrug.org/options.cgi/chat-lrug.org
>>> List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>>>
>> _______________________________________________
>> Chat mailing list
>> Chat at lists.lrug.org
>> Archives: http://lists.lrug.org/pipermail/chat-lrug.org
>> Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org
>> List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>>
>
>
> --
>
> Edwin Wills
>
> CTO
>
> +44 (0)333 240 2222
>
>
> 65 Leonard Street, London EC2A 4QS
>
> www.rentify.com
>
>
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> Archives: http://lists.lrug.org/pipermail/chat-lrug.org
> Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org
> List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>

-- 
------------------------
Andrew Premdas
blog.andrew.premdas.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20201009/f93d5016/attachment.html>