php - What is the best way to implement login for a webservice? -

i have php webservice can called (from mobile phones) perform task. these tasks done, caller must "logged in." best way handle authentication?

currently, i'm using sessions. client calls login api, , other api needed. i'm concerned impact of having 200,000 people calling service , have of sessions. not sure how server respond. tips? how typically handled? facebook, flickr, etc....

if being called custom client program (i.e. mobile phones), , not browser, why "log them in" @ all. rather, use http authentication (either digest or basic if you're going ssl, or own scheme), , "log them in" every time.

then don't have worry sessions, load balancing, , fail over, etc. keep stateless.

addenda:

certainly, fewer hits db better, that's general rule. @ same time, many hits db handled cached pages on db server, or possibly application caches never hit db server. so, in cases, particularly single row queries against indexed column, db hits can cheap.

now, 1 might consider if they're both stored , readily accessed, what's difference between cache bit of database, , unique user session.

well, primarily, difference in contract data. cached item has lifespan directly proportional amount of memory have , amount of uncached activity happening. give small amount of memory, , cached item has short lifespan. give lot of memory, , cached item has better chance of hanging around. if amount of memory cached data large enough repeated activity data continues use cache, cache big win. if cache recycling fast nothing ever "in" cache, cache has no value. point system work or without cache, cache performance enhancement.

a session, however, has different contract. many sessions have specific, minimum lifespan, typically measured in minutes: 10, 20, 30 minutes.

that means if user hit site once, must dedicate resources user if never comes back. have to, otherwise session offer no value.

if lot of traffic, lot of new sessions manage. in theory, under bad circumstance, sessions can spike without limit. if 10,000 hits on site, manage remains of hits minimal lifespan of session. have dedicate resources (memory or disk) them, have keep track of them, , then, inevitably, have clean them up.

a cache fixed resource. grows size configure it. have no obligation keep in cache, , discussed earlier, system function or without cache. caches naturally recycle. if surge of 10,000 hits, they'll possibly roll cache, after leave no mark on system. can hit , gone in 1 or 2 minutes, never seen again.

finally, sessions, need share them among infrastructure travel user if hop machine machine (for whatever reason). caches don't. ideally want keep user local set of resources, caches can job, system works whether move or stay (it works better if stay, because of cache reuse). if don't replicate sessions, don't work @ all.

db hits add up, can cheap, they're never free. session has own costs well, important consider them both , how apply within architecture.