Friendlier work and fileset URLs

[mjgiarlo]

Many of us prefer shorter URLs that expose less of the underlying mechanisms that handle the routing within Hyrax. For instance, users are never exposed to the notion of FileSets in the UI, and other than a small number of Samvera community folks, the notion of a "curation concern" is not widely known and is also not exposed in the Hyrax UI. Thus, consider mapping e.g. the following routes:

/concern/generic_works/* :arrow_right: /generic_works/* /concern/images/* :arrow_right: /images/* /concern/file_sets/* :arrow_right: /files/*

:point_up: These are just examples. We need to get more feedback on the specifics from the community to make sure we approach this work with sufficient and widespread investment.

When we take this on, the old routes should continue to redirect to the new routes.

Related work

https://github.com/samvera/sufia/issues/1382 Rails 5.1's new route functionality: http://edgeguides.rubyonrails.org/5_1_release_notes.html#direct-resolved-routes

[mjgiarlo]

Discussed on Slack today with @vantuyls @dunn @jrochkind @hackmastera. Folks, feel free to add to what I've written above.

[vantuyls]

bump.

this has reared it's ugly head in our production repository as we try to move a work from the "wrong" work type to the "right" one. The URL for the original work now needs to be redirected. can we have a conversation about whether and how to prioritize this work?

[hackartisan]

@vantuyls it sounds like the proposed resolution would not solve your problem, though.

[vantuyls]

right, i suppose what i'm looking for is something even simpler: /concern/fileid

for everything. the utility of the URL/I having that other information embedded i think is outweighed by the ability to have a concise and flexible URL/I.

Use Case: if i want to move a work from one work type to another, i currently have a redirect problem to solve in addition to moving the work type. with concise URIs this would not be a problem.

[julesies]

I agree the use case of moving from one work type to another is likely going to be a need for many institutions since Worktypes and the use of them are evolving concepts. I can see this already happening to us!

[jeremyf]

What we opted for at Notre Dame was to re-route all of the /concern/:type_of_work/:work_id to /show/:id. We then created partials based on the work type, and render those on the "show" page.

I have no problem getting rid of the /concern/:type_of_work/:work_id. The previous concept of having /concern/:type_of_work was to avoid conflicts in URL spaces (after all Hyrax, CurationConcerns, and Sufia are engines mounted within another application, and thus have weird URL rules). Considerations are that you'll possibly want a separate controller for each work type, as they each have different models they use.

See our implementation example: https://github.com/ndlib/curate_nd/blob/master/config/routes.rb#L11-L17

[no-reply]

In general, I'm :+1: on opaque URIs, though I think any effort to remove work types as a URI segment would involve some fairly significant work to dispatch controller behavior.

It sounds like we should probably put some thought into how support redirects when a work type changes. Even if we change future behavior, apps under the status quo will tend to run into this issue eventually.

[mjgiarlo]

@cjcolvar suggested /work/:work_id instead, which has two positives:

1. The URL is short and uses vocabulary consistent with what is presented to users (contra 'concern');
2. Allows for work types to change over time without requiring users to change bookmarks and without requiring software or system changes.

The downside is that supporting this may be complicated given the way Rails routing works and that Hyrax app implementers downstream may (probably "will") want each of these requests dispatched to a work type-specific controller with its own behavior. This is true in the work @tpendragon and his team are doing on Figgy, where e.g., some work types include the file manager component and others do not. In other words, there are good reasons to investigate this pattern but let's make sure to expose the complexity required to make this work, so folks can make an informed decision based on real costs and benefits.

[jrochkind]

Here's how we hacked our local sufia 7.4 app to have /work/:id instead of /concern/generic_works/:id, in case anyone finds it useful.

https://github.com/sciencehistory/chf-sufia/pull/952/files

It mostly works -- and our app is generating those URLs, not just redirecting to them or something. But some weird edge case route generations still create the old ones, haven't tracked down why. We of course redirect the old ones to the new ones too.

We only have one "work type", so dealing with multiple work types, and deciding if we wanted the same or different URLs, wasn't an issue for us.

If it had been, I think we'd still have wanted things like /video/$id and /image/$id, not that weird /concern/generic_work stuff -- internal stakeholders thought the default URLs seemed unprofessional/undone.

[rjkati]

In Hyrax 3.0.2, work URLs still use /concern/generic_works/*, /concern/images/*, /concern/file_sets/*.