|
While I agree the definition of REST can be pretty flexible and there are
no hard and fast rules, I think it is a fairly well established rule of
thumb that the URL should generally identify the resource, not the query
parameters. The body (which I think you mean by "standard input") is where
the payload should go, and should not be used on on a GET request in any
case.
In some APIs the resource is not a "thing" but a function, in which case
it is considered ok to pass query parameters to it in the URL for a GET or
in the body for a POST. The example of this from my favourite REST book
"The RESTful Webservices Cookbook" is a distance calculator. So
/calc_distance?from=wiesbaden&to=frankfurt is ok because "distance" is not
a thing but a function.
Tim.
________________________________
From: WEB400 <web400-bounces@xxxxxxxxxxxxxxxxxx> on behalf of B Stone <
bvstone@xxxxxxxxx>
Sent: 14 January 2019 18:27
To: Web Enabling the IBM i (AS/400 and iSeries)
Subject: Re: [WEB400] Using REST service created with IWS
This is really what makes things difficult in todays APIs world. You have
the option to use query string, resource, or Standard input data for any of
the data passed. Or a combination of all of them. I wouldn't say query
strings are frowned upon by all. Depending on it's use.
Working with Google and Ms and others I've seen all 3 used in some cases.
There is _some_ rhyme and reason as to when to use each, but its not set in
stone. I prefer to keep the URI as simple as possible, passing most
description/selection data as standard input (json mainly.. I suppose you
could use XML).
So, before going and making complex URIs for a RESTful service, look more
into what may work best in the long run. There are hundreds if not
thousands of threads online discussing this.
Bradley V. Stone
https://eur01.safelinks.protection.outlook.com/?url=www.bvstools.com&data=02%7C01%7C%7Ccb90b390820a4d78712408d67a4598be%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636830836659125221&sdata=AiIGw2yQoAvBEgdwQTs%2FHFtWkNXzPNpSOAaygzFUEZM%3D&reserved=0
MAILTOOL Benefit #18 <
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.bvstools.com%2Fmailtool.html&data=02%7C01%7C%7Ccb90b390820a4d78712408d67a4598be%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636830836659125221&sdata=ikOdrXpg9XAyU2vgkegQsb5WeFoYOODUluNQazXlkJs%3D&reserved=0>:
Ability to
use SSL, TLS or OAuth 2.0 authentication. (OAuth 2.0 only available with
Google or Microsoft Office 365).
On Mon, Jan 14, 2019 at 11:07 AM Tim Fathers <X700-IX2J@xxxxxxxxxxx>
wrote:
Peter,customer
I don't know anything about the IWS but I think from what you've posted
you are perhaps confusing two different ways of specifying parameters in
the URL. One method is to use query parameters, which follow the question
mark at the end of the URL, e.g. /customers?id=1234&order=1 The second
method is to specify the parameters as part of the URL itself, so
/customers/1234/orders/1
The first method is considered bad practice in a RESTful API when it is
used to help identify the resource which you are requesting (here
1234 and order 1), it should normally only be used in a RESTful API toadd
further, refining information to the request, such a page numbers and<
filtering, /customers/1234/orders/1?page=1&sort=name
Looking at your pattern, /{email}{casenbr ^[0-9]+$} you are trying to
specify URL type parameters but actually attempting to use query type
parameters. In any case, as Nadir says, the pattern won't work because
there's no way to delimite the email address and case number, what you
probably need is something like this:
/email/{email}/casenbr/{casenbr ^[0-9]+$}
Which would then mean your requesting URL should be /lab_repair/email/
address@xxxxxxxxxxx/casenbr/1234567
Tim.
________________________________
From: WEB400 <web400-bounces@xxxxxxxxxxxxxxxxxx> on behalf of Peter Dow
petercdow@xxxxxxxxx>https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2F1.2.3.4%3A10010%2Fweb%2Fservices%2Flab_repair%3Femail%3Daddress%2540example.com%26casenbr%3D1234567&data=02%7C01%7C%7Ccb90b390820a4d78712408d67a4598be%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636830836659125221&sdata=ZoXJVmfz99O6%2FjN3YRIbAkw%2BCb%2FfWAj%2FMgWFX4KcAS4%3D&reserved=0
Sent: 14 January 2019 17:22
To: web400@xxxxxxxxxxxxxxxxxx
Subject: Re: [WEB400] Using REST service created with IWS
I'm not sure what you mean. If the URL is
the
the parameter name is right there in the URL.
If that's incorrect, what should the URL look like?
On 1/14/2019 7:11 AM, Nadir Amra wrote:
Hi Peter, yes, I know how the gui figures out the parameters, but thereis
no way to determine the email and the casenbr for any URL specified
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fdeveloperworks%2Fibmi%2Flibrary%2Fi-rest-web-services-&data=02%7C01%7C%7Ccb90b390820a4d78712408d67a4598be%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636830836659125221&sdata=BD5u63LyUsMdBkDyF7Gmb1Tl74TyKQluKU%2FCR5GfLsE%3D&reserved=0way you currently define the parameters.04:33:00
"WEB400" <web400-bounces@xxxxxxxxxxxxxxxxxx> wrote on 01/11/2019
PM:
From: Peter Dow <petercdow@xxxxxxxxx>
To: web400@xxxxxxxxxxxxxxxxxx
Date: 01/11/2019 04:33 PM
Subject: Re: [WEB400] Using REST service created with IWS
Sent by: "WEB400" <web400-bounces@xxxxxxxxxxxxxxxxxx>
Hi Nadir,
Thanks for responding -- this was my first time using IWS and I was
following your article (at least I'm guessing you're the same Nadir
Amra) at
parameterserver2/index.html.
And I remember wishing you'd had an example with more than one
to:)
I'm guessing it figures it out by the braces - {} as it does not seem
Defaulthave a problem figuring it out. When it shows the parameters for the
method, it separates them in the drop down for the "Identifier" column
of the Input Parameter Mappings:
Input parameter mappings:
Parameter name Data type Input source Identifier
*NONEValue
PEMAIL char *PATH_PARAM email *NONE
PCASENBR zoned *PATH_PARAM casenbr ^[0-9]+$
Likedetermine
--
*Peter Dow* /
Dow Software Services, Inc.
909 793-9050
petercdow@xxxxxxxxx <mailto:petercdow@xxxxxxxxx>
pdow@xxxxxxxxxxxxxx <mailto:pdow@xxxxxxxxxxxxxx> /
On 1/11/2019 11:29 AM, Nadir Amra wrote:
The one thing I am confused about is how the app server is to
when email starts and casenbr begins.
You may need to put some sort of delimiter between the variables.
ew&m=CCNDKmimbua65OnLAg5ajuhqmW1RUNgUU60YIV1cBPE&s=zDfiqyOfNRaGH9IFEeyWioXMwEUqOaDmlMC0Y9of--0&e=01:06:15
/{email}-{casenbr ^[0-9]+$}
"WEB400" <web400-bounces@xxxxxxxxxxxxxxxxxx> wrote on 01/11/2019
anPM:
From: Peter Dow <petercdow@xxxxxxxxx>
To: web400@xxxxxxxxxxxxxxxxxx
Date: 01/11/2019 01:08 PM
Subject: [WEB400] Using REST service created with IWS
Sent by: "WEB400" <web400-bounces@xxxxxxxxxxxxxxxxxx>
On a v7r3 Power8 box, I used IBM Web Administration for i to create
ADDCASEApplication server called LAB_REPAIR (v2.6 web services).
It's based on a service program, RT0200S that has 2 procedures,
GETCASESTATUS.and GETCASESTATUS. Right now I'm focused on the latter,
on aIt has 2 parameters, email and casenbr. Email is defined as
fixed-length 100a and casenbr is zoned decimal 7.0.
The base resource URL (using ip address for the time being; this is
private LAN only) is
INVALID URI REMOVED.
4-3A10010_web_services_lab-5Frepair&d=DwIGaQ&c=jf_iaSHvJObTbx-
siA1ZOg&r=1i-jGlz0-JTK1aLHcsU-
4-3A10010_web_services_lab-5Frepair-3Femail-3Daddress-2540example.com-26casenbr-3D1234567&d=DwIGaQ&c=jf_iaSHvJObTbx-*NONEThe GETCASESTATUS procedure is associated with the http GET request:
Procedure name: GETCASESTATUS
HTTP request method: GET
URI path template for method: /{email}{casenbr ^[0-9]+$}
HTTP response code output parameter: *NONE
HTTP header array output parameter: *NONE
Allowed input media types: *ALL
Returned output media types: *XML
Input parameter mappings:
Parameter name Data type Input source Identifier Default
Value
PEMAIL char *PATH_PARAM email *NONE
PCASENBR zoned *PATH_PARAM casenbr ^[0-9]+$
I
The service is created and running, and the question is, what URI do
use to test it?
When I trythe following uri in a browser
INVALID URI REMOVED.
ew&m=CCNDKmimbua65OnLAg5ajuhqmW1RUNgUU60YIV1cBPE&s=uK47m9ezZuWUJIH8HkSEyHCGy65_KsLeV_fZGjfUqoo&e=siA1ZOg&r=1i-jGlz0-JTK1aLHcsU-
mailing--I get an HTTP 404 response (not found).
I tried using SOAPui and got the same thing.
I'm new at this REST stuff and really new at SOAPUI, but this really
shouldn't be that hard. What am I missing?
--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400)
u=https-3A__lists.midrange.com_mailman_listinfo_web400&d=DwIGaQ&c=jf_iaSHvJObTbx-list
To post a message email: WEB400@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: INVALID URI REMOVED
ew&m=rcKknnRRUBU8yw9hGaKc042ET2Jq0nTKecodpA1K3Oo&s=o9TNBicq_j5Tf84US2rMycT3iB2BtPXmH-49lTZQBFk&e=siA1ZOg&r=1i-jGlz0-JTK1aLHcsU-
ew&m=rcKknnRRUBU8yw9hGaKc042ET2Jq0nTKecodpA1K3Oo&s=7bdJ2s1T2LPpqlDUzYtB6MCZShD415W9HB77bnRriZE&e=or email: WEB400-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at INVALID URI REMOVED
u=https-3A__archive.midrange.com_web400&d=DwIGaQ&c=jf_iaSHvJObTbx-
siA1ZOg&r=1i-jGlz0-JTK1aLHcsU-
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.midrange.com%2Fmailman%2Flistinfo%2Fweb400&data=02%7C01%7C%7Ccb90b390820a4d78712408d67a4598be%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636830836659125221&sdata=Tx03KOIjmK8LoCaD6omZRgLvvWecd0s55CP%2Fcf13018%3D&reserved=0.
--
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:
or email: WEB400-request@xxxxxxxxxxxxxxxxxxhttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Farchive.midrange.com%2Fweb400&data=02%7C01%7C%7Ccb90b390820a4d78712408d67a4598be%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636830836659125221&sdata=hLuFaOj3zgD6QbtOwQ18f3CwIUMvwgXn6GKIajIZryk%3D&reserved=0
Before posting, please take a moment to review the archives
at
.https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.midrange.com%2Fmailman%2Flistinfo%2Fweb400&data=02%7C01%7C%7Ccb90b390820a4d78712408d67a4598be%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636830836659125221&sdata=Tx03KOIjmK8LoCaD6omZRgLvvWecd0s55CP%2Fcf13018%3D&reserved=0
--
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:
or email: WEB400-request@xxxxxxxxxxxxxxxxxxhttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Farchive.midrange.com%2Fweb400&data=02%7C01%7C%7Ccb90b390820a4d78712408d67a4598be%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636830836659125221&sdata=hLuFaOj3zgD6QbtOwQ18f3CwIUMvwgXn6GKIajIZryk%3D&reserved=0
Before posting, please take a moment to review the archives
at
.
--
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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.midrange.com%2Fmailman%2Flistinfo%2Fweb400&data=02%7C01%7C%7Ccb90b390820a4d78712408d67a4598be%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636830836659125221&sdata=Tx03KOIjmK8LoCaD6omZRgLvvWecd0s55CP%2Fcf13018%3D&reserved=0
or email: WEB400-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Farchive.midrange.com%2Fweb400&data=02%7C01%7C%7Ccb90b390820a4d78712408d67a4598be%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636830836659125221&sdata=hLuFaOj3zgD6QbtOwQ18f3CwIUMvwgXn6GKIajIZryk%3D&reserved=0
.
--
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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.