Re: Using REST service created with IWS

[Peter Dow <petercdow@xxxxxxxxx>]

Thanks Tim.  I did realize that at some point. I suppose having the 
/email and /casenbr in the URL might be good for documentation, but it's 
not absolutely necessary.  It does mean that things are positional 
though, so using *QUERY_PARAM would be more self documenting.

For my purposes, I'm very happy just to get it working either way!

--
*Peter Dow* /
Dow Software Services, Inc.
909 793-9050
petercdow@xxxxxxxxx <mailto:petercdow@xxxxxxxxx>
pdow@xxxxxxxxxxxxxx <mailto:pdow@xxxxxxxxxxxxxx> /

On 1/15/2019 6:49 AM, Tim Fathers wrote:
> I think this reply went missing the first time...
>
> Peter,
>
> We may have had a misunderstanding here somewhere, but in the original example you posted you didn't have the / between the email and case number:
> "URI path template for method:          /{email}{casenbr ^[0-9]+$}"
>
> This was what Nadir was pointing out; that you had no delimiter between the mail and the case number. However, your config below should also be ok (maybe there's something wrong with the casenbr regex), you do not have to mention the words "mail" or "casenbr" in the URL, they have nothing whatsoever to do with the names of the parameters themselves, I put them in because that's would be typically what a URL would look like. You could equally well have:
>
> /email/{email}/case-number/{casenbr ^[0-9]+$}     ---->     /email/test@xxxxxxxxxx/case-number/12345
> /email/{email}/{casenbr ^[0-9]+$}     ---->     /email/test@xxxxxxxxxx/12345
> /dog/{email}/cat/{casenbr ^[0-9]+$}     ---->     /dog/test@xxxxxxxxxx/cat/12345
> /{email}/{casenbr ^[0-9]+$}     ---->     /test@xxxxxxxxxx/12345
>
> Which is the best way depends entirely on your use-case (although I'd avoid using dog and cat 😊 ) and the hierarchical relationship (or not) between a case and an email, so if the case number naturally belongs under the email then the first method makes most sense I think as it is self-evident to anyone looking at it what the path parameters are.
>
> Tim.