On 5 February 2014 14:00, Rakesh <[email protected]> wrote:
> > Anyone see any issues with removing things from the url and moving to > the headers? Kevin, I believe your company has used device recognition > in urls and parameter values - do you think thats a good approach or > just legacy? > > It depends on *why* you want device recognition. If it's just analytics then you can grab user-agent strings from your server logs, though you're better off using javascript to async grab a tracking pixel with query params - much as google analytics does with __utm.gif (and you can still process it by scanning server logs, if you wish). There's some data available to javascript than will be sent in browser headers, so you can harvest more information this way. If you're thinking to serve dynamic content, then don't! It really messes with caching, CDNs, etc. A much nicer approach is to have distinct resources and run the logic on the client to determine what to fetch. You'll also want to consider if a user-agent will always be there. Not all consumers will be browsers, they might well be native apps or other services - being able to do this is part of the appeal of REST. -- You received this message because you are subscribed to the Google Groups "Java Posse" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/javaposse. For more options, visit https://groups.google.com/groups/opt_out.
