Develop Reference

What exactly does it mean to write an API for an OO language?

I have been asked to write an API for a high-level OO language of my choosing (I'll be using Java). The API needs to perform specific functions, of course, but they are very basic things that I know I can accomplish.
I'm familiar with the concept of an API for a web application and that's straightforward enough, but what exactly does it mean to write an API for an OO language? In Java's case, does this mean writing a package that can be imported and provides the desired functionality via classes/functions, so I would write a) the package and b) a separate module to test it? (For clarification, I have been provided no information other than "write an API" and "it needs to do X, Y, and Z". Further clarification: I mentioned the web application API concept just to show that I know what an API is. This is not any sort of web API whatsoever.)

There are different definitions depending on the context and who you ask.
Some people call all public types that are exposed by a module an API. By this very broad definition almost every library or package has an API. I think this is a quite common definition but not everyone agrees with it.
At a more abstract level, an API is a kind of contract or specification that defines some functionality. An API is more like a well defined interface of a module or service that is used to separate the public available functionality from it's internal implementation. A good example of this kind of API are the Java EE APIs.
Practically, in Java an API usually consist mostly of Interface types. The functionality is defined by the methods of the interface and by the documentation. The API itself does not need to have any functionality on its own (it can have some basic default classes or helper classes though).
It's up to another class to implement the interface and provide implementations of the defined functionality. Those implementations shouldn't violate the contract which is defined in the documentation.
If a some application wants to use the API, it only accesses the interface and never the implementing classes. This is the principle "Program to an interface, not an implementation". In my opinion this is the most important aspect of APIs and is what separates the API from regular interfaces. It makes the API reusable and enables the internal implementation to change without breaking the API.
Of course to actually use an API, there has to be some kind of mechanism to get an instance of a class that implements the API. Usually it's some kind of factory method or dependency injection.
The packaging usually depends on the API's usage. API as defined by the first definition usually are included in the jar of their library, because it wouldn't make sense to import them alone. If there are multiple implementations of an API then the API should be be packaged separately from the implementations.

Yes, you just need to write the classes need to implement the desired functionality. Make sure whatever functionality is requested can be accessed by some other programmer using your code. (Methods they need to use should be public for example).

I'd say your assumption is correct - yes, you are asked to write "a package that can be imported and provides the desired functionality via classes/functions."
Then again, I've never written an API. I was trying to imagine an "offline" one, but the examples that come to mind are mostly referred to as SDKs.
Anyway, this is what Wikipedia has to say on the subject:
API in object-oriented languages
In its simplest form, an object API is a description of how objects work in a given object-oriented language – usually it is expressed as a set of classes with an associated list of class methods.
For example, in the Java language, if the class Scanner is to be used (a class that reads input from the user in text-based programs), it is required to import the java.util.Scanner library, so objects of type Scanner can be used by invoking some of the class' methods
import java.util.Scanner;
public class Test {
public static void main(String[] args) {
System.out.println("Enter your name:");
Scanner inputScanner = new Scanner(System.in);
String name = inputScanner.nextLine();
System.out.println("Your name is " + name + ".");
inputScanner.close();
}
}
In the example above, methods nextLine() and close() are part of the API for the Scanner class, and hence are described in the documentation for that API.
So what I read here is, in OO languages, you can think of any class as being kind of an API for something. Swift is an API for building UIs, and the entire JDK itself is an API for building software for anything that can run the Java runtime environment.
In such [object-oriented] languages, the API is still distributed as a library. For example, the Java language libraries include a set of APIs that are provided in the form of the JDK used by the developers to build new Java programs. The JDK includes the documentation of the API in JavaDoc notation.
Also note that...
An API is usually related to a software library: the API describes and prescribes the expected behavior while the library is an actual implementation of this set of rules. A single API can have multiple implementations (or none, being abstract) in the form of different libraries that share the same programming interface.
So basically, whoever told you "it needs to do X and Y" described an API for you (using natural language), and you're supposed to write its implementation - a library, in an object-oriented one. (And years later, some other developer may be writing a new library implementing your API, described by the JavaDoc documentation your produce.)
So yeah, your deliverable is a package that can be imported and used in someone else's Java code.

Design pattern for wrapping a SDK

Our company has purchased a SDK that can be used for Android apps. The SDK is written in java and its very big.
I have to create a wrapper for this SDK so our partners doesn't need to directly use the SDK, but call our wapper functions instead.
I am wondering what is the best design pattern for doing a job like this? I am have been looking at the proxy design pattern, but not sure if this is the correct one.
Many thanks for any suggestions,

The one that comes to mind is the Facade pattern.
From the Wikipedia description:
A facade is an object that provides a simplified interface to a larger
body of code, such as a class library.
The facade pattern is one of the original design patterns that was described in the GoF book. There the description reads:
Provide a unified interface to a set of interfaces in a subsystem.
Facade defines a higher-level interface that makes the subsystem
easier to use.
Seems to fit your use case perfectly.

This sounds like the classic case for the facade pattern. You want to design an API for your partners that captures your high-level use cases. The implementation would delegate to this purchased SDK, but without allowing its implementation details to propagate up to your partner's code.
http://en.wikipedia.org/wiki/Facade_pattern
The proxy pattern looks less relevant to this problem. Proxy tends to be a one-for-one mapping to the wrapped API just for infrastructure requirements. The classic example is remote method invocation.
http://en.wikipedia.org/wiki/Proxy_pattern

The Facade pattern sounds like the most appropriate one.
However, choosing the best design pattern is not a guarantee of success. Whether you will succeed really depends on the nature of the SDK that you are attempting to "wrap", and what you are really trying to achieve by wrapping it.
For example, in a past project I made the mistake of using facade-like wrappers to abstract over two different triple-store APIs. I wanted to have the freedom to switch triple-store implementations. It was a bad idea. I essentially ended up mirroring a large subset of the API functionality in the facade. It was a major implementation effort, and the end result was no simpler. In hindsight, it was simply not worth it.
In summary:
If you can make your facade API small and simple, this is a good idea. (The ideal facade is one that simply hides a whole bunch of complexity or configurability that you don't want the clients to use.)
If your facade is large and complicated, and/or entails complicated "mapping" to the actual APIs you are wrapping, you are liable to have a lot of coding to do, and you may end up with something that is objectively worse than what you started with.

I don't think this question can be answered without knowing exactly how your partners are going to use your wrapper. Design an API that's suitable for them and then just delegate the calls to the appropriate (series of) SDK calls.
You might call that a facade if you wish, but I think your task is bigger. I'd say it's a new layer in a layered architecture. In that layer you can use all the patterns you see fit.

Understand Twitter API

I'm working on a java problem that (at least is trying) to utilize the twitter API, however, it is my first project using any type of API and I am a little confused. What is the benefit of using a java library for the twitter API such as Twitter4J and how would one go about not using one? I'm a little fuzzy on the topic of APIs in general and I'm not finding anything in my searches that really makes it clear how to use one.Do I need to use a Java library or can I do it without one? what are the pros and cons of using one vs not using one. I am relatively new to this and am having some issues. Any help?

First what an API is:
An application programming interface (API) is a particular set of
rules ('code') and specifications that software programs can follow to
communicate with each other. It serves as an interface between
different software programs and facilitates their interaction, similar
to the way the user interface facilitates interaction between humans
and computers. An API can be created for applications, libraries,
operating systems, etc., as a way of defining their "vocabularies" and
resources request conventions (e.g. function-calling conventions). It
may include specifications for routines, data structures, object
classes, and protocols used to communicate between the consumer
program and the implementer program of the API
The use of the Twitter4J API would allow you to easily call commands that do complex operations, such as get tweets as they are coming in. For projects such as this, using an API is best way to go about it as you are also going to be required to get an access key which allows you permission to use the API.
Examples using Twitter4J: http://twitter4j.org/en/code-examples.html

You need to distinguish between an "API" and a "Library"
You NEED the Twitter API: it's the thing that connects twitter to your code. You can use this to send a "post this to my account" command for instance.
You CAN use a library: it helps your code talk to the api, by doing some of the work for you. You can call a function with only a string as parameter, and this function calls the forementioned send-to-twitter API
You can ofcourse say things like that the library has an API, but this would be confusing the situation a bit.
In the end it is quite nice to use the library because it helps you by writing code in your language.

How to create an API for any of the website?

I actually want to ask that what is the way to create an API for sites such as Facebook.. Twitter etc. I am an IT Graduate and do know programming but still wonder that how do people start to create their own set of API's for such websites. And Everyday people have a new API to access the site. Can someone throw light on the standard process that is being followed so as to achieve this ?

I think there is no unique canonical way for the design of a public web API. You could find best practices through.
This will also depend of the complexity of what you want to expose.
Basically you'll want it to operate over standard HTTP and be accessible both by backend systems and by browser client. So you'll choose either XML or JSON as the dataformat as it is supported by everybody.
A common pratice would be to adhere to the REST architecture, but this is only one choice over many. Today REST is a buzz word. So many tend to use it even if not really suited to their needs.
Like any public API, you should take great care of backward compatibility and futureproof design. The whole refactoring thing can be thrown away as you can't break client code when developping new features. A classical way to deal with this is to publish API per version and let the client stick with the version it support.

Check Spring Social. It is a framework to write api to connect to social networking websites. Also for doing that you need to have knowledge of OAuth protocol which is one of the protocols used to allow access to private information with other websites.

Google Query from Java?

I'm writing a Java program, and I want a function that, given a string, returns the number of Google hits a search formed from that query returns. How can I do this? (Bonus points for the same answer but with Bing instead.)
For instance, googleHits("Has anyone really been far even as decided to use even go want to do look more like?") would return 131,000,000. (or however many there are.)
Related: How can I programmatically access the "did you mean" suggestion? (eg searching "teh circuz" returns "did you mean the circus?")
found it: http://code.google.com/apis/ajaxsearch/documentation/#fonje

The Google Terms of Service say this:
5.3 You agree not to access (or attempt to access) any of the Services
by any means other than through the
interface that is provided by Google,
unless you have been specifically
allowed to do so in a separate
agreement with Google. You
specifically agree not to access (or
attempt to access) any of the Services
through any automated means (including
use of scripts or web crawlers) and
shall ensure that you comply with the
instructions set out in any robots.txt
file present on the Services.
Google has ways of making life unpleasant for you / your company if you violate the Terms of Service ...
UPDATE: The second sentence is about the way that you use Google's services ... including their published APIs. It is not entirely clear from the wording what is allowed and what is forbidden; literally speaking "any automated means" is very broad. However a Java app that performed Google searches, screen-scraped the results and repackaged them to provide some value added service would (IMO) be a violation of the TOS. And using Google's published APIs to do the same thing would (IMO) also be a violation.
But that's my opinion, not Google's. And it is the Google opinion that matters. If anyone is thinking of doing something like this, they should contact Google and check that what they are proposing is OK.
The point is that Google is not going to assist people to subvert their search business model. Anyone who thinks they can get away with it based on some clever interpretation of the TOS is going to get burned.

for the first part of the answer, try read the t-o-s; for the "did you mean" part, see: http://norvig.com/spell-correct.html

You may be able to do it "legally" using the Google Java Client Library. I don't know for sure, but they may have some methods similar to what you're looking for, and you won't be violating their TOS.
Google Data APIs Library

You can legally access the Google AJAX Feed API through its RESTful interface:
http://code.google.com/apis/ajaxfeeds/documentation/#fonje
Bing still has a developer program where you can call against their API in a JSON/XML or SOAP matter:
http://www.bing.com/developers