We Keep Coding

REST: Tell client to send only csv and text format

In restfull WS, how to tell client to send only csv and text format file.
In content-type header, client set the format in which it is sending request and in Accept header, client set the format in which it want to accept response.
But how to tell client to send only content-type csv or file ? Is this through some documentation ?

The 415 status code seems to be suitable for this situation:
6.5.13. 415 Unsupported Media Type
The 415 (Unsupported Media Type) status code indicates that the
origin server is refusing to service the request because the payload
is in a format not supported by this method on the target resource.
The format problem might be due to the request's indicated
Content-Type or Content-Encoding, or as a result of inspecting the
data directly.
The response payload could contain a list of the media types supported by the server.

Image you have an endpoint called /textfiles - the developer using your API is usually reading your documentation on how to implement this endpoint. Unless you're not doing some auto-discovery magic (which I guess is still not common).
If we take Facebook for example, they just state in their documentation which files you can send:
We accept the following files: 3g2, 3gp, 3gpp, [...]
Your question:
But how to tell client to send only content-type csv or file ?
is also a bit unclear. When the user has sent the request, he already attached the files he thought he could send. So here you would rather send an error with a message, which files are allowed. So are we talking about some "pre"-requests here?
From a backend developers point of view I can just tell you: It's in the documentation. Handle errors properly, document and your implementing developer will not hate you :)

if i develop a restful application using spring i would set the produces attribute to return csv or plain text ( https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/web/bind/annotation/RequestMapping.html) . if the client tries to request a resource other than csv or text it will recieve an error . probably 415

Parsing multipart response

I have a Java client which calls one REST web service. The web service accepts data in JSON format and produces data in multipart format. The content-type I have set here for calling the web service is 'application/json'
Now, in the java client I have to get the response and separate multiple files that are there in the multipart response. I have used following code to get the response.
ByteArrayDataSource ds = new ByteArrayDataSource(conn.getInputStream(), "multipart/form-data;boundary=" + boundary);
MimeMultipart multipart = new MimeMultipart(ds);
System.out.println(multipart.getCount());
When final line is executed, I get following exception
javax.mail.MessagingException: Missing start boundary.
I understand that when it tries to count the files in the response, it does not understand where to start and stop. So, should the webservice set the boundary where files are separated? If yes, how it is done?
If no, what can be done?

I think your boundary is wrong
The right boundary starts with "--" and then followed by a hash. Try to change the boundary parameter to
"--" + boundary
to see if that helps.

I have also faced a similar problem and found a workaround here: https://stackoverflow.com/a/42548549/5236494
Basically I am using javax mail's MimeMultipart class to parse the Multipart response.

Messed up string value received on the server side - multilingual

I have written client side rest services on php and the server side is on Java.
I am sending a value அகம்.com.my using the client side webservice and trying to perform some operation on the server side. The received value is à® à®à®®à¯.com.my
what can I do to receive the string in the same format. I tried to encode the value into base64 and decoded on the server side but still the received value is different.

Make sure you add a 'content-type' header in your requests.
You need to inform the server what kind of data you're sending so it will know how to process it correctly.
For example, if you're sending plain text in UTF8, you can add the following line in your client code :
header('Content-Type: text/html; charset=utf-8')

Fixed it so posting the solution.
on php end:
urlencode($domainName);
Decoded and used UTF-8 on the server side (java):
domainName= java.net.URLDecoder.decode(domainName, "UTF-8");

Duplicate Namespace in header for error response from SOAP web service

If I send a request with the header like as below .,
<S:Header>
<ns2:transId xmlns="http://test.ws.com/testws"
xmlns:ns2="http://test.db.com/db9">123ASD89EDFE7363</ns2:transId>
</S:Header>
its working fine for success responses also there is no unnecessary namespace exist in the header. But error cases, the response from the web service is sent with the two namespaces using same default identifiers for the header element as like below.,
<S:Header>
<transId xmlns="http://test.ws.com/testws"
xmlns="http://test.db.com/db9">123ASD89EDFE7363</transId>
</S:Header>
because of the above format, the client application is unable to parse the responses.
the client artifact is generated using the clientgen from the wsdl. can anyone please help to find the resolution for the above issue.
Thanks in advance.

Can you describe the issue a little more?
It sounds like you're making an HTTP request with a header that has the value "123ASD...", and that when the server responds with OK (200) then it works as expected, but that when the server responds with an error condition (4xx-5xx) then the response it bad.
is it duplicating the same header twice in the HTTP response headers?
Or is it sending an extra request (like perhaps a redirect)?
Like
GET gets a 301 repsonse with the header and then maybe it sends to an error page but it uses the same header twice or something?
A little more information about the header value (does it change every time?) might help...

Thanks for your response. its a SOAP message with header and body over HTTP and there is no issues with the HTTP. error response is like the soap fault or schema validation error from the server when we send bad soap requests. Its not duplicating the header, but when a soap request sent with the unnecessary namespace xmlns="http://test.ws.com/testws" (it has nothing to do with the header elements but my client app adds this everytime when it sends request ), the web service returns the response including the above one and the needed namespace of xmlns="http://test.db.com/db9". my question is the web service is not using different identifiers when it sends two namespaces. the header value is static during one transaction like sessionid.

Error in a middle of writing to outputstream handling

I'm building an httpserver as part of my academic java course,
The server should only support basic GET and POST requests.
I was wondering if there's an elegant way to handle an error which occures in the middle of writing an html file stream content (and after I've already sent the response headers) into the HttpServer output stream.
By elegant way I refer to showing or redirecting the user to a "Internal Server Error" error page.
I tried re-sending the http response headers with 501 error code, but java throws an exception which claims that the headers were already sent...
One fix would be to read the file's contents into memory, and only then sending the headers and the content, but other problems can arise, and furthermore, I don't want to load huge files into the memory before sending them out as a response.

Once the response status is sent on the wire, it cannot be changed. So if you sent a 200 OK response, you cannot change your mind afterwards. As you found, this presents a problem in case of errors that occur mid response.
As far as I know, the only think you can do is to send a chunked response. See section 3.6.1 of RFC 2616:
The chunked encoding modifies the body of a message in order to
transfer it as a series of chunks, each with its own size indicator,
followed by an OPTIONAL trailer containing entity-header fields. This
allows dynamically produced content to be transferred along with the
information necessary for the recipient to verify that it has received
the full message.
The purpose of this trailer is to give information about the entity body that cannot be calculated before the entity body is sent. However, section 7.1 allows any header to be included in this trailer:
The extension-header mechanism allows additional entity-header fields
to be defined without changing the protocol, but these fields cannot
be assumed to be recognizable by the recipient. Unrecognized header
fields SHOULD be ignored by the recipient and MUST be forwarded by
transparent proxies.
So while you can signal that an error has occurred mid response, it must be conventioned between the two parts how this is signaled. You cannot, in general, use any method you can assume the client will understand as signaling an error condition.
Ending the connection prematurely in a message with a Content-length header is an option, but one that is explicitly forbidden:
When a Content-Length is given in a message where a message-body is
allowed, its field value MUST exactly match the number of OCTETs in
the message-body. HTTP/1.1 user agents MUST notify the user when an
invalid length is received and detected.
That said, while the server must not send a message shorter than he advertises, the client must check for this error condition and reported as such (and proxies may even cache this partial response).

By elegant way I refer to showing or redirecting the user to a
"Internal Server Error" error page.
If you can't send the 'success' response how are you going to send a different response? All you can do is log it and forget about it.