× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Agreed on all of that but in reading Tim Fathers' response, it looks to me like we should be using  queryparm instead of a pathparm?

Like this: http://1.2.3.4:10010/web/services/ftoc?90  ; - or something -   ???

This has been a long trip for me, and fun every bit of the way. That the discussion is about style & form tells me thatI finally got there.  Now that I see what IWS is doing I am astonished that there isn't a lot more discussion about this awesome product.



On 1/14/2019 5:16 PM, Peter Dow wrote:
Hi Booth,

If you already created the temperature conversion example using IWS and have it running, then you can use the "Manage Deployed Services" link, select the correct resource from the list and click the Properties button.

On the General tab that's displayed you'll see

Base resource URL:    http://1.2.3.4:10010/web/services/ftoc

Copy and paste that to a browser's address bar and add the temperature convert, e.g.

http://1.2.3.4:10010/web/services/ftoc/90

The response I get (shown in the browser) is

<CONVERTTEMPResult>
<TEMPOUT>32.22</TEMPOUT>
</CONVERTTEMPResult>

Btw, thanks for all your posts about this subject. Reading that thread was a great help in my project.

On 1/14/2019 2:31 PM, Booth Martin wrote:
Walk me through this.  The temperature conversion example included with IWS...  The address is http://an.iSeries.com/coop/ I want to say F2C and 90, meaning I want the api to convert 90 degrees Fahrenheit to Celsius.   What should that look like?


On 1/14/2019 4:16 PM, Tim Fathers wrote:
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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.