I'm trying to use REST Client for Firefox as a mock form to post multipart file data to a Spring 3-driven controller and subsequent handlers. I have our Web Services project configured such that we are able to send XML/JSON requests, which are marshaled/unmarshaled and consumed in the usual way. When I try to use the enctype="multipart/form-data" (by sending the Content-Type="multipart/form-data"), I immediately get :
org.springframework.web.multipart.MultipartException: Could not parse multipart servlet request; nested exception is org.apache.commons.fileupload.FileUploadException: the request was rejected because no multipart boundary was found
I've been sure to include this in my rest-servlet configuration :
<bean id="multipartResolver" class="org.springframework.web.multipart.commons.CommonsMultipartResolver">
<property name="maxUploadSize" value="100000"/>
</bean>
Thinking that this was a limitation of the commons FileUpload jar version, I tried to older releases, but to no avail. Same with my REST Client, trying both this and this
My ultimate goal would be to have JAXB marshal a specified file into an object that contains a byte[] automatically. For a great reference as to what I'd like to see, this post hits exactly that, but it uses RESTEasy as the implementation, whereas I use Spring 3 (and this cannot be changed).
Ideally, POSTing this XML :
<fileUpload>
<username>user123</username>
<localFileToBeUploaded>path/to/file</localFileToBeUploaded>
</fileUpload>
Would result in an FileUpload object containing the username as a String and the file as either a byte array, InputStream, or actual File object, which gets mapped to some specific controller for handling. I'm comfortable with the XML marshaling, but I'm lost as to how to deal with the file aspect.
Is this possible or am I mixing two different paradigms? I haven't been able to come across anything like this, which leads me to believe I'm a little out in left field. Any ideas or comments would be hugely helpful. Thank you!
This will be available in REST Client 3.1 it looks like: http://code.google.com/p/rest-client/issues/detail?id=100
Related
I’m stuck with trying to connect to my SOAP API. The goal is to retrieve a quote via the “Getquote” function which is available in our webservice and use that quote in an application in Bubble.is. Therefore, I want to make it work through form-data so I can reuse the keys and values in Bubble. I get a succesfull quote through the raw method. See picture
Raw method:
You can see that all my fields are in the body so with the form-data method I put all the individual fields in key and value but I get the error message you see below.
Form data method:
Can someone see what I'm doing wrong? Excuses me for I am just starting. There might be some beginner mistakes in there. Thanks for the help!
SOAP encodes messages by using XML. Form data uses a completely different encoding, which the SOAP server doesn't understand, hence the error.
Although I've never used it, there is a Chrome extension called Boomerang that supports SOAP requests, and which may suit you better.
I am working on already written soap webservice.Now i have to introduce one more parameter in request and provide more details in response.I am using Rsa 8.
My WSDL contains two wrappers Request and Response and included a xsd file in which input and output parameters are defined.What i want to know is that do i need to do manual changes in WSDL and then in corresponding Request and Response java files or there is an auto generated way available.
I want to know the best way to do these type of changes.
you need to do the manual changes in the wsdl for adding request/response parameters and you can use wsimport to generate the codes from the updated wsdl.
I have been into web development from sometime. But recently came across an old technology, REST. I read various places about REST calls, what I have understood about REST service is,
REST service responds back with JSON or XML data, which can be used on client side for rendering the DOM elements.
It enhances the use of HTTP protocol.
The URL difference between a REST call and normal URL is:
REST CALL: wwww.xyz.com/getCart/12
URL: wwww.xyz.com/getCart.php?cartId=12
I got the basic difference, hitting the URL would render a page at the server end and would return the response, whereas making an AJAX Call to the REST service would simply return a JSON or a XML output which can be parsed at the client end.
My question is:
If I make my .php page to render a JSON string, and the application makes a AJAX call to the php page to get the JSON response back and use it on client side to render the DOM, then what is the difference between REST call and a normal URL call.?
How REST calls are configured differently from normal URLs?
There's a lot of misinformation and confusion about REST. I'm not surprised that these three points are what you understood from the information available, but they are wrong.
REST isn't coupled to any particular data format or media type. The most important constraint in REST is the emphasis on an uniform interface, which means in this case that the server should be able to respond with whatever data format or media type the clients accept. Under HTTP, the client will tell what formats it can understand through the Accept header, and the server should comply or fail with a 406 Not Acceptable error.
In the same way, REST isn't coupled to any particular protocol, although it's often convoluted with HTTP. Again, following the uniform interface, the clients should be able to follow any links provided by the server, for any protocol with a valid URI scheme.
The semantics of URLs are completely irrelevant to REST. All that matters to REST is that an URL identifies one and only one resource. The URL is an atomic identifier and the client shouldn't rely on any semantics embedded in it for any operations. The two examples you give are both valid in REST. There's nothing more or less RESTful about any of them.
To answer your question, under a REST application the difference you imagine doesn't exist. Hitting an URL will return a response. If the client is requesting with an Accept: text/html header, it may return the human-friendly html page to be rendered by a browser. If the client requests with an Accept: application/json or Accept: application/xml, it may return a machine-friendly format to be read by another application.
REST is just an architectural style, there is no technical difference.
One of the things that REST defines is that your URL needs to be atomic identifiers that refer to only one resource.
GET /users/:id (return the user with the given :id)
PUT /users/:id (update the user with the given :id)
Here is an answer about using a framework to make a REST API in php.
Rest puts more emphasis on the verbs, like GET, PUT, POST... You can call one method like
/api/Customers
and depending on the verb you use it will do a get, post, put or delete. You can also make more easy URL's like
/api/Customers/{id}/Orders/{id}
instead of making a method that would be
api/GetCustomersOrders?id=x&id=y.
All Web Services are APIs, but not all APIs are Web services.
APIs are application interfaces, meaning that one application is able to interact with another application in a standardized way.
Web services are a type of API, which must be accessed through a network connection.
REST APIs are a standardized architecture for building web APIs using HTTP methods.
I've created a ColdFusion Web Service, but it's returning WDDX instead of SOAP. How do I make it return SOAP instead of WDDX?
Have the <cffunction> return an XML object, and have the "returnformat" parameter be set to "plain".
<cffunction name="GetData" returntype="xml" returnformat="plain">
For complex objects, you need to setup the CFCs correctly. Read: Using ColdFusion components to define data types for web services
update: Or, you can create the XML representation of your object yourself with <cfxml>, then return the XML object with returnType="xml" in cffunction.
You may check out coldbox's XMLConverter Plugin as code sample for converting built-in CF complex types into XML.
A CFC method with access=remote ought to return soap, rather than WDDX. I'm sure I've used this functionality for years. What I'm suspecting may be happening is that the content-type is based on the request a client makes. I would download Soap-UI and test http://your.server/yourCFC.cfc?wsdl to see whether SOAP-UI gets WDDX thrown back at it. If is does, I'm at a bit of a loss, but do report it here anyway and I'll take a further look.
If Soap-UI sees a proper response, take a look at the headers it's sending and compare them to the request you're making (possibly through the browser?)
You can also use Fiddler to record soap-ui traffic and compare that against any other source of requests.
The http request thing above may be completely off, but it's relatively easy to check and I think it's ringing a bell.
You may also want to check the return type of the function you're writing. In order for CF to generate a good WSDL, it needs to be able to extract metadata from the CFC you're returning.
A bit late to the game but were you hitting it as a plain HTTP request and not as with a SOAP packet?
For example were you doing this:
http://api.example.com/something.cfc?method=test&arg1=val1
instead of an actual SOAP request with envelope, headers, body, etc?
The HTTP request returns WDDX by default or JSON by specifying the returnformat, while a SOAP request will return data in the format you are seeking.
I want Play to call a webservice. The webservice accepts application/json and returns this as well. With the following code I'm trying to achieve this. (Note, the headers.put(xxx) are added later in an effort to solve the problem).
WSRequest request = WS.url(targetURL);
request.body = new Gson().toJson(user);
request.headers.put("Content-type","application/json");
request.headers.put("Accept","application/json");
request.post();
The strange thing is that my JBOSS server replies: "Cannot consume content type". If I use my 'Simple REST client' plugin in my Chrome browser, and provide the entire JSON Body GSon created and add the content-type header, I get a valid response. Is this not the way to send JSON to the server? Or am I missing some fundamental piece here?
While checking the API documentation on the WSRequest class i noticed the field mime-type
By setting it as follows JBOSS (resteasy) accepted my request succesfully.
request.mimeType = "application/json";