Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change constructor signature #3

Closed
lucaswerkmeister opened this issue Sep 8, 2021 · 1 comment
Closed

Change constructor signature #3

lucaswerkmeister opened this issue Sep 8, 2021 · 1 comment
Milestone

Comments

@lucaswerkmeister
Copy link
Owner

The signature of request() is nice and tidy at the moment: one object of params (sent to the API), and an optional object of options (controlling how the params are sent to the API: method, max retries, etc.).

The constructor is a bit more messy: it has the API URL, then an object of default params, and then the user agent, which logically belongs with the request options. There’s a hard split between the user agent and all the other request options: you can’t change the user agent for just one request() call, nor can you set any default request options in the constructor.

We probably want to change this, and we probably want to do that pre-1.0.0. The constructor should take the API URL, the default params, and then the default options; the user agent would be an option like any other.

@lucaswerkmeister lucaswerkmeister added this to the 1.0.0 release milestone Sep 8, 2021
@lucaswerkmeister
Copy link
Owner Author

In theory, I suppose the API URL could also be a request option, but that feels strange to me. I think we’ll keep that as the first constructor argument.

lucaswerkmeister added a commit that referenced this issue Sep 7, 2024
This partially walks back f6e28b5. It turns out that the type of the
fetch body affects the Content-Type sent with the request:
URLSearchParams corresponds to application/x-www-form-urlencoded and
FormData to multipart/form-data. For a simple request, the former looks
like this:

    Content-Type: application/x-www-form-urlencoded;charset=UTF-8

    meta=siteinfo&format=json

Whereas the latter looks like this:

    Content-Type: multipart/form-data; boundary=---------------------------384998708438653208232613793789

    -----------------------------384998708438653208232613793789
    Content-Disposition: form-data; name="meta"

    siteinfo
    -----------------------------384998708438653208232613793789
    Content-Disposition: form-data; name="format"

    json
    -----------------------------384998708438653208232613793789--

So using URLSearchParams is already much more efficient, resulting in
fewer bytes being sent over the wire (though in most m3api applications
the majority of traffic will be received from the server anyway; and
note that this only applies to POST requests anyway, not GET requests).

Additionally, it turns out that OAuth 2.0 requires requests to the
access token endpoint to be sent using application/x-www-form-urlencoded
(according to section 4.1.3 of RFC 6749 [1]), and recently MediaWiki
started to enforce this [2], which meant that m3api-oauth2 was broken
for Wikimedia production with all m3api versions since 0.8.0. Using
URLSearchParams when possible fixes lucaswerkmeister/m3api-oauth2/#3.

[1]: https://datatracker.ietf.org/doc/html/rfc6749#section-4.1.3
[2]: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/OAuth/+/1046715
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant