[LRUG] API for complex conditional data

[Edwin Wills]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20201008/67b6465b/attachment.html>