Hacker News new | ask | show | jobs
by dordoka 3005 days ago
He is not a deity, of course, he's "just" the one that invented REST. I guess what you mean is that he's not right about everything he says.

Well, what he exactly says is that URLs should not include versioning, because URLs are the interfaces names and REST estates that interface names should not be versioned, as that implies a breaking change in the API. It's just the wrong place for versioning in the REST way.

But he is not against versioning, as you say, you can use the Accept header. You could also use a custom header if you might, but the canonical way would be the Accept header.

1 comments

I believe that Roy is nerd sniping us, I capitulate. Ok, Roy was wrong, versions in the URL don't break things, they make them stronger. Naming is hard, we republish a semantically related by different artifact and change the name rather than the varying part? Use etags instead? Change the domain?

I totally understand asking for the version (Accepts) during a GET request. If I agreed on that content-type in advance, if I haven't I need to communicate both the url and the content-type along with the version to the clients. We don't have a common container for (url,content,version), things are getting messy. In a package manager, what is the equivalent of a GET request with an accepts header?

    import foo.bar v1.2.3
    import foo.baz v2.1.3

    new_thing = ::v2:foo.baz.new_thing(1)
    old_thing = ::v1:foo.bar.old_thing(2)

Joe Armstrong has a great post on modules and versioning http://lambda-the-ultimate.org/node/5079

I am strongly infavor of immutable code, I think we should be able to import all versions of a library, referenceable by commit hash.

Interesting idea. I usually code with languages that have lib packaging and depencency management systems. Recently I have went back to code on linux C and I quite miss them now. We have pushed the version management to the dependency or build management tools, but it would be awesome to be able to add that meta in code and those tools could also automate the tasks. BTW, wouldn't it be import foo.bar in both? It would be more logical to keep the name of the lib, import it twice, but with different version metadata.

Thanks for the link as well! I would love to see that experimented somewhere and see if it works.