Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I think one of the reasons that you are struggling with this scenario is because (unless we are missing some key information) the interaction is not very logical.</p> <p>Let me explain why I think this. The initial premise is that the user is requesting to create something and has provided some key information for the resource they wish to create. </p> <p>You then state that if that key information refers to an existing object then you wish to return that object. The problem is that the user did not wish to retrieve an existing object they wished to create a new one. If they cannot create the resource because either it already exists or there is a key collision then the user should be informed of that fact.</p> <p>Choosing to retrieve an existing object when the user has attempted to create a new one seems to be a misleading approach.</p> <p>Maybe one alternative would be to return a 404 Bad request if the resource already exists and include a link to the existing object in the entity body. The client application could choose to swallow the bad request error and simply follow the link to the existing entity and by doing so hide the issue from the user. That would be the choice of the client application, but at least the server is behaving in a clear manner.</p> <hr> <p>Based on the new example, let me suggest a completely different approach. It may not work in your case, as always the devil is in the details, but maybe it will be helpful.</p> <p>From the client's perspective it really has no interest in whether the server is creating a new shortened URL or pulling back an existing one. In fact, whether the server needs to generate a new ID or not is an implementation detail that is completely hidden.<br> Hiding the creation process could be very valuable. Maybe the server can predict in advance that lots of short urls will soon be requested related to a event such as a conference. It could pre-generate these urls in quite periods to balance the load on its servers.</p> <p>So, based on that assumption, why not just use</p> <pre><code>GET /ShortUrl?longUrl=http://www.example.org/en/article/something-that-is-crazy-long.html&amp;suggestion=crazyUrl </code></pre> <p>If the url already existed then you might get back</p> <pre><code>303 See Other Location: http://example.org/ShortUrl/3e4tyz </code></pre> <p>If it previously didn't, you might get</p> <pre><code>303 See Other Location: http://example.org/ShortUrl/crazyurl </code></pre> <p>I realize that this looks like we are breaking the rules of GET by creating something in response to a GET, but I believe in this case there is nothing wrong with it because client did not ask for the shortened URL to be created and really does not care either way. It is idempotent because does not matter how many times you call it.</p> <p>One interesting question that I don't know the answer to is whether proxies will cache the initial GET and redirect. That might be an interesting property as future requests by other users for the same url may never need to actually get to the origin server, the proxy could handle the request completely.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload