In the add content workflow generally, the underlying process to add a legal doc in the front-end code goes:
User searches for a document
User clicks on the selected document
Frontend makes a JSON POST request to the backend that says, "Go get foreign legal doc id 123 from your upstream source if you don't already have it, and tell me its local id"
Once that round-trip happens, issue a form POST request with the casebook id and an optional section id to create the resource as the last item in the casebook or section
The backend creates the resource, then returns a 302 redirect to the annotation page for the new resource
This could be improved in a few ways:
Most popular cases already exist locally, so the first roundtrip is often effectively a no-op that only returns the local id.
The two HTTP requests require different data encodings, but there's no reason for the second one to use form encoding—it's just two key/value pairs of short strings.
Create a new endpoint that accepts a JSON POST request containing:
The casebook id
The foreign legal doc identifier
The optional section id
and in one response, have it get-or-create the legal doc and associate the legal doc with the casebook at the proscribed section id, if present. It should return a 201 JSON response with the redirect URL and the internal resource id. The frontend can then choose to redirect the user or not.
In the add content workflow generally, the underlying process to add a legal doc in the front-end code goes:
This could be improved in a few ways:
To improve the apparent and actual speed of the "add legal doc" flow for https://github.com/harvard-lil/h2o/issues/1933:
Create a new endpoint that accepts a JSON POST request containing:
and in one response, have it get-or-create the legal doc and associate the legal doc with the casebook at the proscribed section id, if present. It should return a 201 JSON response with the redirect URL and the internal resource id. The frontend can then choose to redirect the user or not.