This seems to jump into web-based APIs without mentioning it. An API <i>does not</i> have to be web based: it could be a set of classes, or methods, or modules or functions to be used from a language directly.<p>Web services, of course, tend to have web-based APIs. But that's a subset of <i>all</i> APIs.<p>Since this article seems aimed at beginners, I think it's an important distinction to note. You would not want beginners to think that APIs are <i>always</i> web-based because then they'll be confused by things like WebGL, which is also an API but <i>does not</i> involve web requests or AJAX.
As I noted in the article's comments, I'm pretty sure you can't just add "dataType:jsonp" and have it automagically bypass all the cross-domain security restrictions.<p>What actually happens is jQuery appends something like "callback=some_random_function" to the end of the querystring when it makes the request, and then the server is supposed to return you the standard data, wrapped in a function definition with the same name. jQuery then automatically executes the function, making the json data available.<p>Some servers require a specific function name, which can be specified as an ajax option using "jsonpCallback: functionName". All this effectively does is uses a specific function name instead of a randomly generated one, so that it matches up with the function returned from the server in the response.
Thanks for this -- I think I'm your target audience here. CS student, entirely aware <i>of</i> APIs, but not a clue how to interact with them. Yet I now have tweets flying left, right and center. So thanks!
For restful HTTP...<p>I like to keep my API strict resources, and nest them if necessary. Also avoid using more than 4-5 verbs per resource.
<a href="https://github.com/seivan/DocumentationExample" rel="nofollow">https://github.com/seivan/DocumentationExample</a><p>POST, PUT, GET (member), GET (collection) and DELETE on a resource and nothing more.
If a resource needs different kinds of colletions (say a filter) I'd use query parameters.<p>This makes working with API's as a consumer so much easier, especially as a iOS developer. :-)<p>Very Rails like, I know. I tend only to use the resources and/or resource method keywords. No custom matches and etc. Not for the API anyways.
Just my two cents.
I feel like this is missing something, perhaps a working demo.<p>I'm experienced in php and jquery but after 2 days of fiddling and stack overflowing, i could not get my demo api to POST...any helpful links are appreciated.<p>I was especially confused with php/cURL. .ajax seemed a bit more straightforward but jquery/javascript is so dang hard to debug. for cURL do you have to have any (non-default) settings installed on your servers?
>So, $.ajax in JavaScript (jQuery) and cURL in PHP. That’s it.<p>This is a bit confusing. "That's it" makes it sound as though this is the complete scope of what people mean when they say API. Somewhere it should be made clear that we are talking about one API of a particular type.<p>After reading the post someone could come away with the idea that if you don't have .ajax and jQuery or cURL and PHP then you aren't using an API.
It's "a beginner's guide" that starts with an explanation of what an API is and then jumps straight into PHP code with cURL!<p>When someone just learnt what an API is and doesn't have a clear idea of what it is or how it works an example code doesn't help at all.<p>When I'm asked to explain what APIs are these are the things I mention,<p>- an API is a fancy name for 'a way to talk to an external service'<p>- when you need to do something with an external service like Twitter you have to use their API to communicate with them<p>- an API is like a 'contract for communication' which specifies how to talk to the external party<p>- Most web APIs use the HTTP protocol as a way of communication to send messages back and forth and they also have a method of representing data, for example JSON or XML, that's just the same thing but a different way, using JSON or XML is like saying the same thing in English or Spanish, using the HTTP protocol or something else is like writing down a sentence vs shouting it out.<p>- When you use Twitter's API to unfollow someone, you don't know how exactly the unfollow happens, you don't have to know, all you know and have agreed with Twitter is that you ask Twitter to unfollow someone and they will do it, so in a way, using the API you are just sending them a 'signal' to do something. They can go ahead and change the inner workings of that API and as long as the part that is exposed to you remains the same you don't care because as far as you are concerned it does the same thing even though it may be doing it in a very different way<p>Here's a trivial example of a real-world API,<p>Imagine you run a restaurant and you need to buy fresh supplies to cook your delicious dishes every day.<p>You hire someone and teach them to buy the supplies as you order. You trust them to buy good quality stuff and deliver them to you.<p>You agree to give them order instructions via SMS. And you agree on the following format:<p><pre><code> BUY
15 Salmon Fish
20 Avocados
DELIVER BEFORE 30 January 2013 14:00
END
</code></pre>
Now the person you have hired can use your 'Order API' to work with you. You send them a message in a format that you have agreed upon and using a medium that you have agreed (SMS).<p>Hope that helps some beginner who is struggling with all the fancy terms being thrown around without explaining the principals and the simple details that everyone takes for granted once they have passed the initial learning phase.
I think the term SDK should be in there - it goes hand-in-hand with API in terms of "traditional" development that's not web-based. I understand he didn't go there because he doesn't do that himself, but jes' sayin'.