This is a single archived entry from Stefan Tilkov’s blog. For more up-to-date content, check out my author page at INNOQ, which has more information about me and also contains a list of published talks, podcasts, and articles. Or you can check out the full archive.

Indigo and REST

Stefan Tilkov,

Clemens Vasters teaches Indigo to do REST — part 1, part 2. Very, very cool stuff. One minor gripe I have is with this paragraph(s):

Now we assume, for a moment, that every customer in the system had its own HTTP service endpoint. If you have a million customers, you have a million endpoints, probably looking like this: http://www.example.com/myapp/customers/00212332. Each of these endpoints has an implementation of the shown interface, representing the resource. […] I think that you probably even could create a million endpoints, but of course such an application would be a complete pig. I haven’t tried and I don’t think you should.

That seems to somehow confuse problem and cause — http://www.example.com/myapp/customers/00212332 seems like a perfectly fine URI to me, and at least one company definitely has a few million of those … the fact that URIs map to a scarce resource (an endpoint) in existing stacks is the problem, not the URI.

On December 13, 2005 12:04 AM, Clemens Vasters said:

The first assumption is that you’d have an endpoint listener for each URL. That’s what I am saying there, not more.

On December 13, 2005 8:23 PM, Mark Baker said:

Millions of URIs doesn’t mean millions of software objects.

http://www.example.com/myapp/customers/00212332

and

http://www.example.com/myapp/customers/23042343

can share the same instance of a software module/object, as well as an HTTP connection, when being interacted with via HTTP. Just not at the same time, of course, as that would require a new instance. All the software need do is bind to “/myapp/customers/”, extract the remainder of the path themselves to get the customer id, and then do a db lookup with that id.