Verb/Noun vs Noun/Verb URL structure

[jace]

All our apps use noun/verb or collection/noun/verb URL structures, where the entity that the user is interacting with appears in the URL before the action being performed on it (with no verb slug if the action is viewing). Examples:

• https://metarefresh.talkfunnel.com -- noun, implicit view verb
• https://metarefresh.talkfunnel.com/edit -- noun, explicit edit verb
• https://metarefresh.talkfunnel.com/2015 -- collection+noun, implicit view verb
• https://metarefresh.talkfunnel.com/2015/edit -- collection+noun, explicit edit verb
• https://hasgeek.tv/metarefresh/ -- noun, implicit view verb
• https://hasgeek.tv/metarefresh/2014 -- collection+noun, implicit view verb
• https://hasgeek.tv/metarefresh/2014/edit -- collection+noun, explicit edit verb
• https://hasgeek.tv/metarefresh/2014/843-a-front-end -- collection+collection+noun, implicit view verb
• https://hasgeek.tv/metarefresh/2014/843-a-front-end/edit-- collection+collection+noun, explicit edit verb

Verbs are finite, nouns infinite. Having the verb appear before the noun in a URL eliminates any chance of namespace conflict. However, the view verb is the use case 90+% of the time and having it appear in URLs is meaningless cruft, so we've taken to using noun/verb order on all sites built after Hasjob. Hasjob continues to have /view/jobid URLs.

In noun/verb URLs with implicit view, verbs can conflict with nouns, so verb names have to be reserved against use as nouns (typically new, edit, delete). Note that these are not the same as the HTTP verbs POST, PUT and DELETE. Hyperlinks can only be GET requests, so there always has to be a GET version of a verb from which the user can initiate the action.

With Hasjob, we don't have a clear sense of how to remove the view/ prefix from jobpost URLs. Alternatives:

1. https://hasjob.co/<jobid> -- jobs at the root level. This precludes future use of hasjob.co/employer URLs
2. https://hasjob.co/<domain>/<jobid> -- makes it apparent from URLs where the job is. Domains always have a period in them while Lastuser usernames never do, so we're saved from potential future namespace conflict. However, draft jobs don't have a confirmed email domain, so their URLs could change. We'll need backup URLs for drafts, like /new/<jobid>.
3. https://hasjob.co/<profile>/<jobid> -- where profile is a user or organization. However, usernames are not a well defined feature with Hasjob users and organizations don't exist yet and there is no upgrade path for old jobs.

If approach 2 is the way to go, the URL endpoint currently at /at/<domain> changes to /<domain>. Webmail-listed jobs will now become /gmail.com/<jobid>, exposing these domains for the first time, but this is not a concern as (a) all other domains have long been exposed, and (b) webmail domains are on the wane as they are banned for any non-partnership listings.

[rudimk]

Option 1 doesn't make much sense to me, if we look at the long-term. While I prefer going with /<domain>/<jobid>since it would let users check out jobs from, say, ibm.com with greater ease, I'd rather go for /<user>/<jobid>. This seems to tie in with Lastuser profiles we have planned.

But the downside is, as of now, it's usually an organization that posts a job on Hasjob - which is why we don't allow webmail accounts to be used for job posts. If we go for 3, would we change that rule?

[jace]

Option 3 has serious disadvantages as it is premised on the user's account being stable. We know from experience that users (a) don't understand usernames and get confused by them, (b) don't know that user accounts are for humans only and organizations should get an organization account, and (c) don't want their personal identity associated with the listing because they are performing a secretarial service.

[rudimk]

Yes, which, when coupled with the fact that we don't allow personal emails, makes a strong case for not going with 3. I suppose 2 it is, then, from my end.

The only disadvantage with 2 of course, is what you've already mentioned - draft jobs don't have a confirmed email domain, but I suppose having something like /<new>/<jobid> or /<draft>/<jobid> would work, wouldn't it?

[jace]

Yes.

[rudimk]

@shreyas-satish @karthikb351 what say you?

[jace]

Draft edit URLs could also remain at the current /edit/<jobid> path.