Security is no secret. For web services you can do it in two basic ways:

1) Use Authorization: Basic base64(username:password) from the client. Because this sends the password with each request, you obviously should only do this over HTTPS.

2) Set a cookie on the server if the client provides the right name/password to some "login" service. When this cookie is present in future requests, assume the user is authenticated (for example, that cookie my also be a key into a session database that authenticates the user, or be a signature of the user ID.) The cookie should probably have some timeout mechanism in addition to the basic browser timeout values, because someone who sniffs the cookie can re-use it without enforcing the browser time-out. Using cookies without HTTPS is somewhat sensitive (see the Firesheep attack) so I recommend HTTPS there, too.

There are other options, like issuing an explicit token, and making it explicitly part of the URL or a custom header, rather than using cookies -- same security profile; harder for developers who already know HTTP to understand.

Finally, if the source of identification or authentication is a third party, like OpenID, there are other mechanisms as well.

Are you sure about status field? Isn't HTTP code enough?

If the data is transferred outside of a HTTP-aware wrapper, then the HTTP status will be lost.
This can happen in a few ways:

1) Inside the application, it's common to pass along a dict<string, object> or similar representing the decoded body
2) If using on-disk caching separate from HTTP caching (which may be necessary when using out-of-band invalidation channels) you're reading a file, not a HTTP server, and would have to somehow synthesize a HTTP response if your unit-of-information is at the HTTP level
3) If you switch to other transports, such as message queues or push notifications, there are no HTTP status codes (see for example Facebook Mobile's use of MQTT)