It means that you enable objects to be accessed through some means. In your examples, you could let the users [create, read, update or delete objects][1] (usually abbreviated to CRUD) using the HTTP protocol through some predefined way to interact with your objects (an [API][2]).

That API can adhere to a set of rules - e.g. [RESTful][3] APIs use [HTTP verbs][4] to perform some actions on objects and they adhere to [some principles][5] that say how resources should be identified/represented and how they should be manipulated through those representations.

In the context of a web application, let's say you have blog posts stored in your database. You would like the users of your application to be able to do something with those posts. They don't have to necessarily use your *web site*, but could perhaps use their own application that would connect to your application (e.g. a blog reader program).

As the owner of your application, you could define an *interface* through which your application can be accessed. For example, you might want to add an option for some users to read or write blog posts. The interface could look something like this (for an example of a more complex API, see [Twitter's API definition][6]):

 - If a `GET /posts/{number} HTTP/1.1` is requested from your web application, you will provide a representation of your post object with an id `{number}` in a predefined format

Note that you are not providing an actual database object, nor your application object. You are providing a *representation* of your object

 - If a `POST /posts HTTP/1.1` with a `title={text1}&body={text2}` is posted to your web application, you will create a new post object titled `{text1}` that will contain `{text2}` for its body, and will return an id value of the newly created post

Again, you are allowing the user the manipulate *representations* of your objects. The user does not have to know how your objects actually look like (that is *abstracted away* by the interface from the user).

Exposing the object means providing the user with an interface to access and manipulate your objects. If that interface satisfied some additional predefined conditions regarding representations of the object and states of the application that exposes its objects, then that interface is said to be a REST (or RESTful) API.


  [1]: http://en.wikipedia.org/wiki/Create,_read,_update_and_delete
  [2]: http://en.wikipedia.org/wiki/Application_programming_interface
  [3]: http://en.wikipedia.org/wiki/Representational_state_transfer
  [4]: http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol
  [5]: http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
  [6]: https://dev.twitter.com/docs/api/1.1