Re: Using REST service created with IWS

I have been following this thread while working on a project to consume a
REST service from RPG with an external system.

In my case there are a lot of options that are required in the HEADER.

In IWS you can define a parameter type as HEADER (think this was shown in
a previous response)

How do you include the header settings in the call.

I am using HTTPAPI and it provides a call back to handle this.

Just curious

Thanks


Don Brown

"WEB400" <web400-bounces@xxxxxxxxxxxxxxxxxx> wrote on 16/01/2019 05:22:16
AM:

From: "Peter Dow" <petercdow@xxxxxxxxx>
To: web400@xxxxxxxxxxxxxxxxxx
Date: 16/01/2019 05:22 AM
Subject: Re: [WEB400] Using REST service created with IWS
Sent by: "WEB400" <web400-bounces@xxxxxxxxxxxxxxxxxx>

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.

--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing

list

To post a message email: WEB400@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/web400.


______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud

service.

For more information please visit http://www.symanteccloud.com
______________________________________________________________________

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________