Multipart-based API redesign #48

New Issue

Jef Roosens · 2024-02-11T09:23:50+01:00

Jef Roosens commented

2024-02-11 09:23:50 +01:00

The current API requires POSTing to one of /f, /s or /p, with possibly a specific key. While this works, it's not the cleanest API, as the keys are shared between the routes and the resulting entry is not placed at e.g. /f/abc, but rather /abc.

If we add multipart form support to LNM, we could instead migrate to using a multipart-based API instead. Entries would be PUT'ed to /somekey, with the first part of the request containing the metadata for the entry to add. For redirects, this metadata would already contain the URL, meaning no other parts are needed. For files and pastes, the second part would contain the binary data of the file described by the leading metadata.

The metadata payload could either be a custom binary format, or some known format such as JSON (although this would require us to write a full parser).

The current API requires POSTing to one of `/f`, `/s` or `/p`, with possibly a specific key. While this works, it's not the cleanest API, as the keys are shared between the routes and the resulting entry is not placed at e.g. `/f/abc`, but rather `/abc`. If we add multipart form support to LNM, we could instead migrate to using a multipart-based API instead. Entries would be PUT'ed to `/somekey`, with the first part of the request containing the metadata for the entry to add. For redirects, this metadata would already contain the URL, meaning no other parts are needed. For files and pastes, the second part would contain the binary data of the file described by the leading metadata. The metadata payload could either be a custom binary format, or some known format such as JSON (although this would require us to write a full parser).

Jef Roosens added the

Kind/Enhancement

label 2024-02-11 09:23:50 +01:00

Jef Roosens commented

2024-02-11 10:30:57 +01:00

Poster

My current idea is to add a layer of abstraction to the reading of HTTP body data from the request. Instead of accessing the read buffer directly, LNM would instead expose a "read body" function which reads data from the current body, be it a regular body or part of a multipart request. This function would currently delimit reads between bodies, allowing the framework to transparently split the bodies as needed. Some string variable would also be present which describes what the current part is the user is reading from.

To process parts, the user would define multiple steps, with each step processing a specific part of the multipart request. This would allow for easy integration into the current design of steps, with the body read functions emitting lnm step errors, allowing easy composition into a step.

My current idea is to add a layer of abstraction to the reading of HTTP body data from the request. Instead of accessing the read buffer directly, LNM would instead expose a "read body" function which reads data from the current body, be it a regular body or part of a multipart request. This function would currently delimit reads between bodies, allowing the framework to transparently split the bodies as needed. Some string variable would also be present which describes what the current part is the user is reading from. To process parts, the user would define multiple steps, with each step processing a specific part of the multipart request. This would allow for easy integration into the current design of steps, with the body read functions emitting lnm step errors, allowing easy composition into a step.

Sign in to join this conversation.