As always, most of this is taken from codecadamy’s awesome course on learning ruby and the twitter api.
The response you get back has a structure, just like the request does. It’s made of three parts:
A response line, which includes one off the three digit HTTP codes.
A header, which includes further information about the server and its response. A good example is when it tells you the what format the response will be in, like XML with the utf-8 character set.
The body, which contains the text of the response, either in JSON or XML.
I think I can understand which part is which a bit better for this example than for the request one, but that may be because this example is more clear.
Quick aside, I always heard about UTF-8, especially where I work when we were having issues with foreign characters, and never really understood what it was. This article did a good job giving me a gist of it. Basically, prior to it a lot of people used ASCII, which had the ability to store a certain amount of characters (like 256 I think). 32-127 were for the normal english alphabet, but then from there it could be whatever, and lots of people put lots of different things in there. Unicode (aka UTF-8) was a different way and concept of storing those, which allowed for a crazy amount of characters to be stored, hopefully covering any languages and their character requirements. It’s important that this is set for a page, in a meta element and as the first thing in the header element, because if it’s found later in the HTML, the site will stop and restart its reading of the code in that character set.
Ok good talk, back to API stuff.
XML stands for Extensible Markup Language, and is very similar to HTML. They both use tags in angle brackets, but the big difference is that XML allows you to use tags that you make up, rather than just the standard ones from W3C, aka the World Wide Web Consortium.
XML vs. JSON
So when you do an API request, the response can be in XML or JSON, but the only way to know which it will be is by reading the documentation of the API you are working with. The documentation is key for any API you use, as it tells you what the API expects from you when you send it a request and what you can expect from the API when it sends you a response.
They had me do a practice request to check the status of a website (they had shown how to do this at the beginning of the course), and I was actually able to do it! The hints were definitely helpful though.
After that and some other questions, I finally finished this course on how to use API’s with Ruby. Fuck yeah! Next up, time to actually do the twitter project.