Rails same top-level URL route for organizations/user: domain.com/user and domain.com/organization works the same

Question

I'm attempting to make it so that top level-routing works from my Rails API to an Ember.js client in this manner (similar to how GitHub works, for example):

Hitting www.example.com/username would give you a user's page. This would either hit the api.example.com/users/:username endpoint or some other endpoint.

Hitting www.example.com/organization_name would give you an organization's page. This would either hit the api.example.com/organizations/:organization_name endpoint or some other endpoint.

When getting a random URL, the client will obviously have no idea what type of model it's dealing with. It will just treat it as www.example.com/random_string, where random_string is either a username or an organization_name.

I'm not quite sure how to deal with this situation. It's unclear where the responsibilities lie with client or server here. I can imagine maybe some sort of polymorphism working here, but can't connect the dots.

EDIT

It looks like this is ostensibly possible on the Rails side by having a catch-all route for /:slug and then using the slug to first query for a User, and then query for an Organization.

The bigger question, then, is whether it make sense to handle these requests by rendering with an existing controller action, or by letting HTTP handle it with redirections. Will ember-data handle the HTTP redirections well? And in the other case, will it be able to appropriately switch types on this endpoint?

Answer 1

It looks like this is ostensibly possible on the Rails side by having a catch-all route for /:slug and then using the slug to first query for a User, and then query for an Organization.

This is the only viable approach. You need at the very end of your config/routes.rb file to add this catch-all route. I advise you to associate this route to a proxy method in your controller which is going to determine if a User or an Organization record corresponds to the slug.

Knowing that you must consider the application action when a User and an Organization have the same slug (some will prioritise one of them, some will give the 2 choices to the visitor) ; and the action to take when no record correspond to the slug (some will display a 404, some will route to a listing page). Those choices will help you to determine the better design for your proxy method.

The main thing here is to design this proxy method.

1- HTTP redirect

Your proxy method will respond a redirect_to to /users/:slug or /organizations/:slug depending on what's found from the slug.

• Advantage: easy and fast to write and maintain.
• Disadvantage: slow application response due to the HTTP redirect and the need to re-access the database during the second request.

2- Ajax response

Similar to HTTP redirect, but done in AJAX. Your proxy method would display a page containing JavaScript code that fetch the content of /users/:slug or /organizations/:slug and display it through AJAX.

Additionally the URL could be changed by JavaScript using history.pushState

• Advantage: a little bit faster than above
• Disadvantage: but harder to write, necessitate JavaScript code plus js view, and it is still necessary to re-access the database during the second request

3- Server side proxy

Your proxy method would perform the same code as your endpoint method. Meaning that if the slug is found to correspond to a User record, the proxy method would do the same as UserController#show. (And same goes for Organization)

This means that the proxy method must call all before/after filters that UserController#show would, and render the same view.

Be very cautious if you choose this solution to DRY. Or you may end up with difficulties to maintain your app.

There is not a single method to do this, and it all depend of your application architecture. If for example your show method is just fetching the record and rendering the view, and if there is no controller helpers methods, than it's easy and safe. On the other hand if you have filters and controller helpers methods than it get a bit more tricky. In this case you may want to rely on controller Concerns.

• Advantage: fastest solution
• Disadvantage: can be very complex to write, and depending of the evolution of your code-base in the future, you may end up in a locking situation where you would be obliged to give up this design.