I am trying to receive data from an external API which contains data in Greek language from my express backend however when I print the response I only see � instead of the Greek letters. I have tried sending different charsets in the API call but to no avail.
Is there something I am missing? I don't have any experience in handling different languages
I looked at the response headers and found out that it was using windows-1253 encoding so I used a library windows-1253 to decode the response.
My bad I didn't thought of looking at the response headers earlier
Related
enter image description here
What this picture actually describes?
I have a confusion, which is, whenever we are sending a GET request to the server via a API,
are we sending it in JSON format ?Or, in HTML or any simple Text format?
On the other hand, whenever the API is sending a request (HTTP verb actually) to the server, is it using HTTP format? and the server also returns a response in HTTP format or in JSON format?
I know this question is very silly....but I am very new in API world.
The picture is not accurate, the server sends a response and the MIME type does not matter, it can be even RDF n-triples or images depending on the type of the service and what it supports. The protocol is always HTTP, though theoretically it is possible to use a different protocol. REST has some mandatory constraints, you can read about them in the Fielding dissertation or I wrote about them here and here.
I have been writing iPhone applications for some time now, sending data to server, receiving data (via HTTP protocol), without thinking too much about it. Mostly I am theoretically familiar with process, but the part I am not so familiar is HTTP multipart request. I know its basic structure, but the core of it eludes me.
It seems that whenever I am sending something different than plain text (like photos, music), I have to use a multipart request. Can someone briefly explain to me why it is used and what are its advantages?
If I use it, why is it better way to send photos that way?
An HTTP multipart request is an HTTP request that HTTP clients construct to send files and data over to an HTTP Server. It is commonly used by browsers and HTTP clients to upload files to the server.
What it looks like
See Multipart Content-Type
See multipart/form-data
As the official specification says, "one or more different sets of data are combined in a single body". So when photos and music are handled as multipart messages as mentioned in the question, probably there is some plain text metadata associated as well, thus making the request containing different types of data (binary, text), which implies the usage of multipart.
I have found an excellent and relatively short explanation here.
A multipart request is a REST request containing several packed REST requests inside its entity.
We are implementing a REST interface, and we've decided to use application/atom+xml as the output format, as it gives us a nice standard way to return a list of items together with links to the related details.
However, we are struggling to find a standard way how to return errors. I know that setting a proper HTTP error code would be required, but what about the message? Atom 1.0 RFC does not mention error handling at all, Atom Publishing Protocol RFC says the response should contain a human-readable entity with error message. However, this does not help much. What MIME type should be ideally the response? Plain text? HTML?
Is it OK that if the client sends Accept: application/atom+xml, we return Content-Type: something else? Or would you rather recommend to embed the message into an Atom Entry? I'd like to stress out that the interface is meant for machines, not human users.
Thanks a lot for your suggestions.
I'm designing an API to be as HTTP compliant as I can. This includes sending specific response codes back and using the Accept header to specify versions and response types.
I understand this may appear subjective, but I'm sure there's a conventional way of doing this. I have a set of response types that the API supports, along with a vendor-specific mime type to specify the type and version.
Currently, when the client specifies a non-existant version or type, I'm just returning a 400 Bad Request with an empty body, however, I want to return a useful error message. In the event that I don't know the response type, I feel a bit dirty responding with plain text (or defaulting to JSON). Is there a header I'm missing, or some convention that I should follow? I want to get this one right from the offset.
Thanks, and my best,
Jamie
Try the status code of 406 Not Acceptable.
http://support.microsoft.com/kb/943891/
This is a list of HTTP sub-codes supported by Microsoft IIS. I've found this page damn handy since it gives you some insight into the messages they use to handle various errors. There are some HTTP sub-codes that refer to headers.
I have a really weird WCF problem here...
We're connecting to a crappy third-party web service; it was a nightmare to even get it going, we had to create a custom WCF binding since those guys decided to use "ISO-8859-1" as their text encoding (instead of UTF-8 like everyone else on the web), and the other settings were messy, too - and not documented anywhere, of course...
It's been working ok for a while now, but suddenly, some of our data coming back in mangled up. We expect to get back names of places, and being in Switzerland, some of those have German umlauts in them. But for the past two or three months, we suddenly get back
Hünibach
instead of the proper
Hünibach
So the ü (u umlaut) is mangled.
No problem, I figured they finally switched to UTF-8, and I changed my custom binding to use UTF-8 as its text encoder instead of ISO-8859-1 - but no luck - no I'm getting:
EXCEPTION: System.ServiceModel.Security.MessageSecurityException
The HTTP request was forbidden with client authentication scheme 'Basic'.
What the f????? The service is protected by a username/password which we pass in using the ClientCredentials of WCF. Seems that changing the text encoding somehow messes up the credentials !?!?! Weird.....
OK - back to ISO-8859-1, and I just tried to interpret the response payload as UTF-8 - again no luck :-( Tried with UTF-16, UTF-32, UTF-7 even, Unicode, BigEndianUnicode - all to no avail.
So how on earth do I get back my proper umlauts, and still be able to call that bloody service... works just fine in SoapUI, btw.....
Any ideas?? I'm desperately grasping at any straws you might throw me!!
Try inspecting the data you are getting back and see what numeric codes they are using to represent it. Umlaut is one of those characters in 8859-1 that shares code with other characters.
See second para in - http://en.wikipedia.org/wiki/%C3%9C#Typography
Actually, I finally figured out what the trouble was.
For some reason, changing the sample CustomTextEncoder (provided by Microsoft in the WCF & WF samples) to use UTF-8 instead of ISO-8859-1 doesn't work.
On the other hand, ripping out the custom text encoder from my custom binding and just using the standard TextMessageEncoder that WCF provides from the get go (which uses UTF-8 by default) did work.
Don't ask me why.... that's just the facts I found.....