[katello-devel] Modelling of environments, products, etc in Katello (related to renaming of environments)

[Lukas Zapletal]

> The original resource still exists, only its location has changed.
> Since we cannot know how API clients use resource urls, how long
> they keep them around, etc, we either: have to return the resource,
> its new location, or notify the user that the resource in question
> has been deleted. That is the reason why http response codes
> differentiate between "not found" (404) and "permanently moved"
> (301).
> Think how many times you followed a link and got a 404, only to
> discover later that it still exists, but at a different URL? Let's
> not contribute to this problem.

This plan has one little snag - 99 per cent of our API clients will be
just some scripts that will totally ignore 301 or whatever. They just
work or not. This is the reality.

It's the REST that makes you feel you are doing something wrong, while
everything is perfect. I could take your opinion and apply it on a
regular API. As an example you can take any API from UNIX that has some
kind of a get_value("value_name") function. Or Java for example is
better, method like getOptionValue("name").

Good Java API designer introduces ValueNotFound exception which is
thrown when value does not exist. Poor Java API programmer just return
null. I agree with you having 404 is a good thing and we do that
already. So far so good.

But tell me, how many API designers introduce ValueRenamedException that
is thrown when someone renamed option value? I have never seen this. In
our case it should be unchecked exception, because forcing users to
catch this would be suicide.

Now, don't get me wrong, but this is what I call over-engineering.
Taking one concept (from HTTP) and applying it somewhere else. I can
imagine how 404/301 is annoying *on the web*, but not in case of API
over HTTP.

Resource was there, it is not. That's the simple fact API consumers will
need to deal with.

-- 
Later,

 Lukas "lzap" Zapletal
 #katello #systemengine