<p dir="ltr">Perhaps it is just me being conservative. While you may think the features are fundamental, usually it is also true that there are different ways of doing things. In this case, web routing. And I also like preserving the original implementation if it is harmless to do so and there may be projects that depend no the current implementation. That's how I usually approach projects. </p>
<br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El mar, 1 de oct de 2024, 21:31, Mark Volkmann <<a href="mailto:r.mark.volkmann@gmail.com">r.mark.volkmann@gmail.com</a>> escribió:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">Sure, I could create subclasses of classes in the WebClient package to add the missing features. I’m curious how it is decided when it’s appropriate to do that rather than improve the existing classes. The features I’m proposing seem like fundamental web features, so I thought it would be better to improve the existing classes so everyone gets access to those features without needing to use new subclasses.<div><br id="m_-2599858589101827523lineBreakAtBeginningOfSignature"><div dir="ltr">---<div>R. Mark Volkmann<div>Object Computing, Inc.</div></div></div><div dir="ltr"><br><blockquote type="cite">On Oct 1, 2024, at 7:21 PM, Mariano Montone <<a href="mailto:marianomontone@gmail.com" target="_blank" rel="noreferrer">marianomontone@gmail.com</a>> wrote:<br></blockquote></div><blockquote type="cite"><div dir="ltr"><p dir="ltr">Can't you implement as a subclass and/or separate package (that depends on webclient package)? I had that at some point.</p><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El dom, 29 de sept de 2024, 11:41, Mark Volkmann via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st" target="_blank" rel="noreferrer">cuis-dev@lists.cuis.st</a>> escribió:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I've been digging into the WebClient package which can be used to implement HTTP servers in addition to sending HTTP requests. It has these three shortcomings:<div><br></div><div>1) It doesn't support paths containing path parameters. Request matching is done through Dictionary lookups and doesn't work when there are path parameters. For example, you can define a route for "GET /dog", but you cannot define a route for "PUT /dog/:id" to update a dog with a given id.</div><div><br>2) It doesn't support query parameters. For example, in a request like "GET /car?size=small&color=yellow", there is no method that will return a DIctionary containing the query parameters size and color.</div><div><br>3) It doesn't support PATCH requests. These are used to update a subset of the properties of a given resource, unlike PUT requests which update all the properties.</div><div><br></div><div>I can fix these shortcomings, but before I do that I want to verify whether there would be interest in possibly merging my changes. If not then I can just create my own fork of that package.<br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div><font face="arial, helvetica, sans-serif">R. Mark Volkmann</font></div><div><span style="font-size:12.8000001907349px"><font face="arial, helvetica, sans-serif">Object Computing, Inc.</font></span></div></div></div></div></div></div></div></div></div></div>
-- <br>
Cuis-dev mailing list<br>
<a href="mailto:Cuis-dev@lists.cuis.st" rel="noreferrer noreferrer" target="_blank">Cuis-dev@lists.cuis.st</a><br>
<a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" rel="noreferrer noreferrer noreferrer" target="_blank">https://lists.cuis.st/mailman/listinfo/cuis-dev</a><br>
</blockquote></div>
</div></blockquote></div></div></blockquote></div>