SOAP API Client Issues
As far as I can see based on responses to questions around the SOAP API, it is recommended to use the REST API instead; however we have a need to use the SOAP API since the REST API does not provide some of the capabilities we require. So, I have been working on implementing a Java SOAP client and I have run into several major issues.
Our ideal implementation would be to use JAX-WS to generate the client side Java classes from the WSDL. This is not possible using the current SOAPInterface WSDL as RPC Encoding is not supported by JAX-WS.
I also attempted to use Axis 1’s wsdl2java as described on the site to generate the classes, but again ran into issues. The generated classes do not compile with Java 1.6 due to Axis 1’s use of the Java keyword enum as a directory name (ex. org.apache.axis.enum.Style.RPC). In order to compile the classes, the highest version of Java that could be used would be 1.4. Using this version is out of the question.
I have also attempted to alter the WSDL to be Document/literal as opposed to RPC/literal in order to use JAX-WS, but am running into issues around this and if Screen Scraper’s endpoints check specifically for rpc, this will not work.
Are there any workarounds or other suggestions you might be able to provide?
Alternatively, are there any plans to update the SOAP API to Axis 2 based, or perhaps to make the REST API more consistent with the other methods of invoking Screen-scraper externally? This is a major blocker for us.
Thanks.
Hi, You're correct that we
Hi,
You're correct that we strongly recommend using the REST API. The SOAP API is on the brink of deprecation, so we likely won't be updating it unless there's a compelling reason to do so.
On the topic of the deficiencies of the REST API, however, could you provide a few more details on where it's lacking? If it's a choice between fleshing out the REST API or upgrading the SOAP API, we would definitely opt for the former. If you could just outline methods and such you find present in SOAP but missing from REST there's a good possibility we can get you going in the right direction.
Thanks much,
Todd
Discrepencies between SOAP and REST APIs
Todd,
The main issue we have come across with the REST API is that it does not provide corresponding behavior to the SOAP API. Our intent would be to accomplish the same functionality as is described in the Java SOAP example, http://community.screen-scraper.com/SOAP/Java_example; start a scraping session, add variables to that session, run the scrape, retrieve variables from the session and end the session.
As I understand, with REST it is difficult to retrieve the variables from the session before it is terminated and the variables are then out of scope. This is key functionality for us, so it would be ideal if the functionality between the REST and SOAP API’s were to match in this fashion.
Thanks
You're correct that this is a
You're correct that this is a hole in the functionality of the REST interface. We've decided to remedy it. If you upgrade to version 6.0.45a of screen-scraper you'll get a couple of new features that should allow for the functionality you've described. You can see an example of usage in the code contained in this zip file:
http://community.screen-scraper.com/files/media/tutorials/tutorial4/rest/ss_rest_example.zip
You'll want to use it with the shopping site example as described in tutorial 4:
http://community.screen-scraper.com/tutorials/tutorial_4/0_scraping_a_shopping_site_from_an_external_program
Please give that a try and let us know how it goes.
Thanks,
Todd
Question on return type of "Get Session Variable"
I have already answered my own question. I had to tweek how I was structuring the data in the scraping session.
Todd,
I am able to successfully retrieve String variables from the session, however when I attempt to retrieve a DataRecord variable containing another DataRecord a null value is returned.
SUMMARY is a DataRecord session variable which contains other DataRecords, I can see this output in the ScreenScraper log files but the following is the response returned from the REST call:
{"response":{"status":0,"data":{"SUMMARY":null}}}
Thanks.