How can i call a restfull web service by a web browser if i have complex objects like hashmap or arraylist on the server side.I have found sample java clients but no help for doing it from web browser..
For instance if my web service waiting an arraylist of string objects how to differentiate this from a service which expects more than one string parameters on the input url.
That very much depends on what the server accepts as the body of your HTTP request and what it can return. In REST, there is no such thing as a List of Strings. You pass and receive Representations of Resources.
So what are your Resources? What are their Representations?
Related
Due to the fall of SOAP::WSDL which had generated me real Perl modules I have to look for something other in order to handle a SOAP service. The generated modules won't work starting from Perl v5.18.
I have the following situation with my web application.
I have a PSGI compatible, Dancer2 driven, persistent web application.
The web application handles multiple concurrent customers.
The web application is between the customer and an external SOAP service.
The SOAP service uses customer sessions via cookies which have to be integrated on the web application internally for the customer.
The web application holds an WSDL file copy of the SOAP service.
I'm looking for a module that creates an interface out of the WSDL file and handles parameter/schema validation and communication with the SOAP service. I would like to call a method (SOAP call) with parameters (SOAP call parameters) and receive a cleaned data or object structure of the response.
The problem is that the web application needs to handle multiple concurrent customer cookie sessions. So I need a module which offers the possibility to override the cookie jar for that particular request and extract the cookies after the request without causing interference with other concurrent requests.
I found XML::Compile which I can initialize as a singleton at web application start up. But with this solution I ran into problems with interfering other customer requests. So the requests are not separated. Initializing XML::Compile for every request is not the solution either because it will parse the WSDL and generate handlers over and over again for every request the customer sends to the web application.
Is there any solution/module that fits my needs or do I miss something with XML::Compile and it's possible with it?
Are you using Catalyst?
I've been happy using Catalyst::Controller::SOAP and its companion Catalyst::Model::SOAP to build SOAP/WSDL servers and consumers, being able to integrate Perl Applications even with Microsoft Document Literal-Wrapped thing.
Even if not using Catalyst you may probably learn from its code. It uses XML::Compile::WSDL11.
Suppose that I have Apache/lighttpd or whatever to receive http requests. Now I want the web servers to act as a proxy for my web services running on internal servers written in Java/Clojure/Erlang?
What I want is to separate the layer that handles client connections and the server that handle application logic. These two should be separated and language independent. Is JSON or XML the format for communicating? If so, how do I perform it from the web servers?
Note: May be I missed the point of your question in this response. Pls do let me know if that is the case.
I dont think you should consider this as "forwarding" of the original request.
If your web-tier that receives the original request makes a call to one/more underlying services (thru HTTP or otherwise) it is part of the "processing" of the original request.
So, there is nothing different here than what you are already familiar with.
i.e You make a HTTP request in place where you would make a SOAP/XML request or a DB call or post a message.
When you say or think in terms of "forwarding", it is misleading.
Also, the data exchanged between your controller and services is solely based on your convenience.
It could be XML or JSON or regular POST parameters that gets sent over HTTP transport
I made a web service endpoint and exposed a method now i wanna add more parameter to my method
so each time i change in my method i have to regenerate my client. Is there any way so that i
dont have to generate my client again and again.
No, there is no way. If you change the method then the WSDL file is changed also. Web services communicates through SOAP between client and server. When you deploy your web service application and it has been changed, so how then client supposed to know if there is a new method or a new parameters added if the classes was generated from the old WSDL file. Client will send a SOAP request according to the old WSDL and the server won't be able to understand the SOAP message received from the client if there was any changes made to WSDL part related to the received message.
You could design a better webservice/endpoint that accepts a standalone xml document as argument so that the operation signature stays the same, even when you add more parameters.
More generally, it's bad form for a web service to expose it operations as literal method signatures.
I want to send an XML file to a Web Service.
The Web Service is a java application.
I know the endpoint of the Web Service.
Typically I know I have to create the request and send it as an http/https request.
What I want to know is what would I have to make to send the request - as in what development tool could I use e.g. Visual Web Developer (preffered as I am familiar with this) or Visual Studio? And what sends the request - e.g. another Web Service, a Website etc?
Where do I even begin with this?
Any comments are much appreciated.
Where do I even begin with this?
One purpose of a Webservice is loose coupling. So it depends on what you want to do. You can write a simple program in what ever language which constructs a request and sends it. You can write a Webservice on its own which uses the other Webservice to handle it's own requests.
You can handle this in a very simple or complex way. You only need to be able to generate a request (per xml) and send it.
I'm looking to add a web services interface to an existing server application. The set of services to expose is not known at compile time and can change over the runtime life of the server.
From a tech standpoint all the server/web services endpoints will be on Windows.
In our server app a user will have the option to register workflows as 'web services callable'. This will create the WSDL defining this particular workflow service.
For the calling endpoint I'm thinking of an HttpModule that accepts the inbound web service request, unpacks the request and converts the XML data types into our server applications "domain", calls the server and finally converts the server outputs back into XML for return down the http connection.
Does that make sense?
Critical comments welcomed.
In effect writing your own WS engine. Clearly doable, but quite a bit of work to get right from scratch. I guess if you find some open source implementation, then adapting it should be possible.
A rather dirtier alternative, but one I've seen applied in another context, is to go for a simgle WS interface
String call( String workkFlowName, String payload)
The payload and response are both Strings containing any XML. So the caller needs to undestand the schemas for those XMLs. From the client's perspective the amount of coding effort is not much different. Your coding effort would I think be significantly redcued.
an HttpModule that accepts the inbound
web service request, unpacks the
request and converts the XML data
types into our server applications
"domain", calls the server and finally
converts the server outputs back into
XML for return down the http
connection.
That is what all web service frameworks do (e.g. Metro, Axis). So I can't see your problem. What's your concern with this approach?
The downside for the client is that, as far as I understand it, availability of your services may change over time. So you should consider a way to inform the client if the service is available (other than getting a time out error because it is not there), e.g. WS-ResourceLifetime or UUDI.
I ended up creating a C# class that implements the IHttpHandler interface. The implementation serves up the WSDL of the services exposed from our app and accepts SOAP posts to invoke the services. In the end most of the work went on converting SOAP types to our types and vice versa.