Questions about ISD with REST 2.0 binding

Dedicated to DataStage and DataStage TX editions featuring IBM<sup>®</sup> Service-Oriented Architectures.

Moderators: chulett, rschirm

Post Reply
qt_ky
Premium Member
Premium Member
Posts: 2895
Joined: Wed Aug 03, 2011 6:16 am
Location: USA

Questions about ISD with REST 2.0 binding

Post by qt_ky »

All of our current ISD apps are deployed using SOAP over HTTP and tested using SoapUI. Now I am getting into REST and JSON and have a bunch of questions.

I have deployed a simple test job in ISD with REST 2.0 binding and the GET HTTP Action and have managed to piece together the URL (according to the pattern outlined in the documentation) and was able access it OK, eventually. :)

1. In the ISD Console when viewing deployed applications, with the app expanded and the service selected, there is an empty field called URL. Why is the URL empty, and when you click the View button next to it, why does nothing happen? Are these the expected behaviors? I was hoping to get the URL from here instead of manually piecing it together.

2. I have deployed the REST 2.0 test without having selected confidentiality for https. I found that using http:// in the URL leads to an IE error that the page cannot be displayed. If I use https:// prefix then it works. But I did not enable https. Why the surprise here?

3. When testing using the org's standard web browser, IE11, every test prompts with a pop up about what to do with the results - open or save. Open pops up the results in a new window, like Notepad. What are some more efficient ways to test and view the results?

4. Has anyone got suggestions for useful naming conventions on the ISD applications, services, and operations? Our existing ones are quite lengthy and difficult to look at. What might a user-friendly one look like?

Thank you!
Choose a job you love, and you will never have to work a day in your life. - Confucius
eostic
Premium Member
Premium Member
Posts: 3838
Joined: Mon Oct 17, 2005 9:34 am

Post by eostic »

1. URL. Didn't even know that existed, and I deploy these things all the time...must not have been there when we first released the REST binding quite a few years ago. I memorized the url format and never looked back. ;)

2. Have wondered the same thing, but suspect that it is somewhat historical. The REST binding was added many moons ago, in 8.5, and "everything https" for Info Server was done in 11.3. This is a remnant behavior...

3. I would expect that you should only see that with JSON as the protocol. XML should display directly in your browser. Most of the browsers seem to default to wanting to save json to disk. I will often use DataStage Hierachical Stage as a client to test my json stuff, or else find an available tool on the web.....search http plugins for your browser...there are tons of them...

4. Keep it simple if you can...I have done some as simple as (Application) list (service) all (operation) products. ...so that the url becomes something like:

https://myserver:9443/wisd-rest2/list/all/products

(with or without arguments).... design and attach a stylesheet and you instantly have a nice little report..... I also tend to use all lower case for simplicity, although I am not entirely sure if it is case sensitive or not [but I suspect that it might be].

Ernie
Ernie Ostic

blogit!
<a href="https://dsrealtime.wordpress.com/2015/0 ... ere/">Open IGC is Here!</a>
qt_ky
Premium Member
Premium Member
Posts: 2895
Joined: Wed Aug 03, 2011 6:16 am
Location: USA

Post by qt_ky »

Thanks for you quick response.

1. The "URL:" field may be a non-functional stub, or perhaps it gets populated if some other http actions or formats are chosen. Not sure.

2. Ah right, all the various client connections moved to https by default out of the box on 11.3. I think that would explain this behavior as well.

3. Yes, that was with using JSON as the test. OK, searching...

4. Thanks for your example. It's clever.

I ran some quick tests and found that all the parts in the URL are case-sensitive. Change any case of the URL and you get HTTP 404 - page not found error. Change the case of your argument name, and it does go through and you do get results back, however the argument you sent as input was interpreted as having the null value, because you didn't actually provide the correct argument name. Makes sense. All good!
Choose a job you love, and you will never have to work a day in your life. - Confucius
Post Reply