<div dir="ltr">I think my choice would depend on the behaviour of the current UI and the data it stores.<div><br></div><div>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?   </div><div><br></div><div>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.</div><div><br></div><div>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.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 8 Oct 2020 at 11:04, Andrew Premdas <<a href="mailto:apremdas@gmail.com">apremdas@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hey there,</div><div><br></div><div>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</div><div><br></div><div>1) Mimic the wizard via a POST and a series of PATCH calls</div><div>2) Flatten the wizard into a single POST call</div><div><br></div><div>The first approach would require around 6 calls to complete the task</div><div><br></div><div>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" <br></div><div><br></div><div>My questions for the group?</div><div><br></div><div>Which choice would you make?</div><div>Are there alternative approaches to consider</div><div><br></div><div>Thanks for any input/help</div><div><br></div><div>All best</div><div><br></div><div>Andrew<br></div><div><br>-- <br><div dir="ltr"><div>------------------------</div>Andrew Premdas<div><a href="http://blog.andrew.premdas.org" target="_blank">blog.andrew.premdas.org</a></div></div></div></div>
_______________________________________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org" target="_blank">Chat@lists.lrug.org</a><br>
Archives: <a href="http://lists.lrug.org/pipermail/chat-lrug.org" rel="noreferrer" target="_blank">http://lists.lrug.org/pipermail/chat-lrug.org</a><br>
Manage your subscription: <a href="http://lists.lrug.org/options.cgi/chat-lrug.org" rel="noreferrer" target="_blank">http://lists.lrug.org/options.cgi/chat-lrug.org</a><br>
List info: <a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" rel="noreferrer" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
</blockquote></div>