Proposal for new version of lookup-by-base-path

[alphagov]

Proposal for new version of lookup-by-base-path

[kevindew]

GET does seem the semantic choice for this. How many of these do you look up with a single request? Do we know if we have a limit since it's just an internal request?

Longest base_path we have is 799 characters percent encoded.

Re: "draft returns details of the content item currently in the draft content store. There should always be a draft object."

I like that this matches up with the "unpublishing" implementation on get content 👍

it would be closer to the semantics we use in other places if draft was nil when there isn't an active draft. Eg if you run document.draft you get nil for instance, and if you requested something that is in draft we'd return nothing rather than live one. This scenario could well make sense as an exception to that as it's base_path specific but thought I'd make you aware that it could be an inconsistency so it can be considered.

Also.. would you want locale returned too? for content that is in multiple locales the content id is only half the picture.

[MatMoore]

Sounds like an interesting URL we've got there 🤔

We're not normally going to be sending a massive amount of base paths, but I think we could still hit limits like this one. The multi-base-path form of the request is only used in a few places:
https://github.com/search?q=org%3Aalphagov+lookup_content_ids&ref=searchresults&type=Code&utf8=%E2%9C%93

The biggest usage seems to be for translating related item tags into content ids. I don't have good data on this but the largest amount of ordered_related_items (the link type we use in content tagger) tagged to a page is 11. We also have pages that have loads of related things with different link types, eg https://www.gov.uk/api/content/guidance/beginners-guide-to-export-controls.

I was a bit unsure about always returning drafts (I assume you mean "if you requested something that is not in draft we'd return nothing rather than live one"). I don't have a good reason for differing from the standard semantics though, so I'll make it return nil unless there's an active draft.

Good point about locale. I'm not sure we need it, since link-set-tagging affects all editions of a document regardless of locale. But I'm happy to add it if it's useful more generally.

[kevindew]

yes - it's loaded up with utf8 characters percent encoded (a whole other problem)

hmm maybe we can make it respond to both GET and POST and make a decision on which one of those based off number of base_paths in API Adapters?

yeah locale sounds like it'd be good for general purpose.

Less of a risk than linkables but what do you think about adding a limit to the amount of base_paths we accept? Just something big like 1000?

[MatMoore]

👍 to both of those suggestions. I'll start implementing something today.

[MatMoore]

Have started the work in #822