Nobody Understands REST or HTTP

Post by hcarvalhoalves » Mon, Feb 27, 2012, 7:31 PM UTC

lhnz wrote: post #46

hcarvalhoalves wrote: post #32

A lot of good points there, but the part about detecting mobile devices is a bit short sighted. Varying your content based on mobile User-Agent (or any User-Agent actually) renders public caches almost impossible to get right.

>> Varying your content based on mobile User-Agent (or any User-Agent actually) renders public caches almost impossible to get right. Interesting. What would you recommend doing instead, supposing, for example, that you are meant to be returning a different set of items depending on a device identifier, and that you have to support 100s of devices? Should this be considered a different resource instead of a different…

At your cache layer (e.g. Varnish), you would need some VCL to collapse all the hundreds of User-Agents options into something sane like "X-Device", feed this header to your backend, and vary the content based on that instead. This way you can cache just a few representations per resource (e.g., "Desktop", "Mobile", "Tablet", etc.) instead of several hundred. The problem, of course, is maintaing this list of User-Agents.

On his mobile example, it's much easier to simply be pragmatic and serve content for different devices at differents URIs/domains altogether. It doesn't break if you can follow some kind of convention, such that the URLs from one map directly to the other (for instance, mysite.com/news/article -> m.mysite.com/news/article) and then you issue redirects accordingly.

Post by Vitaly » Tue, Feb 28, 2012, 2:52 AM UTC

nirvdrum wrote: post #22

almost wrote: post #6

Earlier quoted context omitted.

With a RESTful API you don't tend to need IDs most of the time, you just use URLs. So having all the versioning info in the URL is not so great, you change the version and suddenly all the URLs aren't valid anymore. But more important that is upgrading a version on an API may not be an all or nothing thing. You might want to start using the new features of the API on one resource type but you aren't ready to upgrade…

Huh? The whole point of having a version in the URL is so you can roll out a new set of URLs and their corresponding endpoints without touching the old ones. When v2 of the API comes out, you still support v1. That's no different than using headers. If you sunset or change an API call, the header isn't going to save you any trouble. In fact, since the client now won't get a 404, but rather something else, the cost of…

you are somewhat missing the point. the idea of proper REST is that you NEVER should generate your urls. you take them from the resources. now suppose you have an application that consumes RESTful API.

if you do it "wrong" you probably store record ids in your local db and then access stuff from the API by constructing your own urls.

a more proper way of doing it is to store the compete resource urls and not just ids. but in this case you have a version update problem. When you release a new version of the app that supports new version of the API you will now need to go over all the stored resource urls and update the version, probably doing some regexing etc.

with version in the headers you can store full resource urls and not have to change them every time api version changes.

Re: Nobody Understands REST or HTTP

Re: Nobody Understands REST or HTTP