More Informative Error Message on selecting unavailable languages in api requests

[curiousCheck]

Current Behavior:
https://api.mangadex.org/manga/18f3e34b-2bad-4e35-8ea6-a0cbae52f76b/feed?translatedLanguage[]=null

{
    "result": "error",
    "errors": [
        {
            "id": "9c346772-7b14-5982-b4b6-7b5888522762",
            "status": 400,
            "title": "validation_exception",
            "detail": "Error validating /translatedLanguage/0: Does not match the regex pattern ^[a-z]{2}(-[a-z]{2})?$",
            "context": null
        }
    ]
}

https://api.mangadex.org/manga?originalLanguage[]=jp&limit=0

{
    "result": "ok",
    "response": "collection",
    "data": [ ],
    "limit": 0,
    "offset": 0,
    "total": 0
}

Spoiler: what?!

for the hundredth time curche its ja not jp

Suggestion:

{
    "result": "error",
    "errors": [
        {
            "id": "9c346772-7b14-5982-b4b6-7b5888522762",
            "status": 400,
            "title": "validation_exception",
            "detail": "Error validating /translatedLanguage/0: Does not match supported languages",
            "context": null
        }
    ]
}

P.S.
Obligatory, RIP NULL/Other chapters

 

[rdn]

Spoiler: Don't put your poodle in the microwave

I remember having this discussion about locale validation before v5 was released. My strong position has always been: if you're looking for the wrong thing, its on you. The machine was operated in the exact way it was built for, put garbage in, get garbage out.
While "jp" is valid according to ISO 3166-1, we specifically mention ISO 639-1 in our docs, where the locale for Japan is "ja", not "jp".
I my mind, you can upload whatever you want to the "jp" locale, but noone will see it if the frontend doesn't include it in its filters, which it won't.
Given that the documentation has been very clear about which specification we expect, you're sending wrong data and expect us to fix it for you or slap you over the head with a RTFM in more diplomatic words.

If you're a developer who is using our API on the terms laid out in the documentation, which you have read, I expect to not have to put out stickers about what not to do. Like microwaving poodles.
Within this framework we can talk about what is dumb or needs to change.

Having said that, our (final) locale validation is based on the symfony intl component which uses php locale check. If that comes back green, we allow it.

 

[curiousCheck]

While I understand your point, I think you're looking at it from a different view

This just came up writing one-time requests to just quickly check the output, be it for support or to try out new features, using hoppscotch or postman or whatever
I wasn't using any tools or programmatically writing scripts/bots to make this request, in which case I have been more careful
It's on me to have guessed it rather than to use it right the first time

And the suggestion was to give a little nudge to when something might be wrong. Like, how you know you're missing chapters in Group's Feed because of your filters, or how many ask about knowing when there's a chapter by a blocked group even if for simple reason we forget

Spoiler: sidenote

I realise the latter is a shit example because I don't really like how Discord shows blocked user messages. Altho I did like how xenforo completely blocks users and only brings up a blocked user's comment if there's a comment below that qoute replies it and maintains context: so there's still room for ideas

In a slightly similar way, I thought if the api does recognize it as an invalid locale, it can just send that in the error: like a stack trace that gives you the error from 3 libraries within maybe?

Spoiler: but then again..

you could say my analogy doesn't work because someone using the api isn't your average user and should be expected to be more.. careful, for lack of a word

In the end, I don't mind not seeing a more informative error: I'm fine with debugging when I know I might've done something wrong. Just that, this time, I thought maybe I'll make a forum post just in case its possible

Nevertheless, thanks for taking time to reply

PS

Spoiler: reply qoute

you can upload whatever you want to the "jp" locale, but noone will see it if the frontend doesn't include it in its filters, which it won't

ohboi
but again, I don't think the api allows it now. instead could just go all in and send the uploads straight to /dev/null...

PS2

Spoiler: about microwaves and metal

i have continued to resist the urge to put a metal cup inside a microphone but have avoided it for (monetary) reasons.. but maybe I'm just a psychopath for that

 

[curiousCheck]

Apologies for piggybacking on this related thread to ask another question
I think this is a good informative error message that a user sees when they (accidentally) do a GET /auth/login
Especially the part where it hints on using POST instead of GET

Is this perhaps a leaking info or was this intended

{
  "result": "error",
  "errors": [
    {
      "id": "5931215f-c270-5b6e-8a3c-ed0981589568",
      "status": 405,
      "title": "method_not_allowed_http_exception",
      "detail": "No route found for \"GET https://api.mangadex.org/auth/login\": Method Not Allowed (Allow: POST)",
      "context": null
    }
  ]
}

 

[RogueKitsune]

Is this perhaps a leaking info or was this intended

Considering the API docs are public it is very much not a leak and is probably intended


Also, auth/login endpoint is deprecated and doesn't work for any one who has created their account or changed their password after OAuth as introduced