Skip to content

Why isn't api unified? #463

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

Closed
Aqendo opened this issue Aug 23, 2023 · 7 comments
Closed

Why isn't api unified? #463

Aqendo opened this issue Aug 23, 2023 · 7 comments

Comments

@Aqendo
Copy link

Aqendo commented Aug 23, 2023

  1. Why, for example, in InputMediaVideo thumbnail parameter is called "thumbnail", while in InlineQueryResultArticle it's called "thumbnail_url"?
  2. Why you can't use multipart/file_id/url sometimes to pass parameters. Example: you CAN pass thumbnail as multipart in sendVideoNote, but you CAN'T pass it via multipart in InlineQueryResultArticle.
  3. Why you can't edit inline queried message if it doesn't have inline button attached to it? There is a lot of these quirks that doesn't make any sense for users/most bot developers.
  4. Why there is a lot of formats to upload medias with? For example sometimes you should use InputMediaVideo, but in sendVideo you should use just InputFile
  5. Why documentation doesn't have any computer-readable format? It seems like doc was written entirely by hand and has almost no opportunity to be scraped (hello botapi framework makers who wanna generate code for their library)
  6. On every platform (ios, android, desktop) at least thumbnail parameter acts differently. On desktop client ignores it AT ALL, on android it doesn't ignore it until you try to see the thumbnail in music player (then it can be changed to absolutely random one if there is no thumbnail in mp3 file)

These questions blows my mind everytime I want to create a bot on this platform.

@levlam
Copy link
Contributor

levlam commented Aug 23, 2023

  1. Because bots can pass InputFile, a URL, or a file_id as "thumbnail", but only a URL as "thumbnail_url".
  2. Bots intentionally can't upload files when they answer inline requests and are forced to use previously uploaded files or file URLs. Uploading up to 50 files would make the requests extremely slow, unreliable, and will ruin the whole experience of using inline mode.
  3. Because bots aren't supposed to edit messages without user interaction. This is likely not to work anyway due to rate limits.
  4. InputMediaVideo is used in methods where multiple media formats are allowed.
  5. It wouldn't help to write bots. Purpose and value of frameworks is in simplification of interaction with API; raw Bot API requests can be send much easier without any framework. There is no way to improve valuable framework part with machine-readable documentation, despite it can save up to 30 minutes a month for maintainer of the framework.
  6. It is up to the apps, how to use provided by the bot data to show inline results in their interface. They must show the received audio, but it is up to them, whether they need to show the thumbnail. If you expect that app's behavior is just a bug and not intended, then you need to create a ticket at https://bugs.telegram.org for the app.

@Aqendo
Copy link
Author

Aqendo commented Aug 23, 2023

  1. This doesn't seem like intentional behaviour. If I respond to an inline request without botapi, i.e. directly via mtproto (e.g. using telethon), it turns out that I can upload a new file, even 50 files, in response to an inline request. The code and a screenshot of the behaviour is attached below. So it's not how bots are built per se, but how it's implemented in botapi. Code: gist . Image of behaviour:
    image.
  2. This is a great omission. As an example, a bot for audio/video/photo downloading. It can't download all 50 files in one row of results, but it can download it after chosen_inline_query update and then just edit original inline message. But, a bot can still edit messages if there are buttons, yes, but for example a bot that draws a graph. Inline gives a reply with buttons describing options on how to draw a graph, after the user clicks on the button it starts to draw a graph, creates a new picture file, and can't upload it, because you can only edit inline message with files already saved on telegram servers. I have no idea why this is done in such a way that you can't upload a file while editing an inline message.
  3. I don't think botapi was intended to be used with curl or alternatives. Every bot with more than 10 users is written on some framework one way or another. If it was so easy to use, there wouldn't be all sorts of aiogram, python-telegram-bot, telebot and others.

@levlam
Copy link
Contributor

levlam commented Aug 23, 2023

you can only edit inline message with files already saved on telegram servers

Because it is impossible to upload files to a different datacenter.

If it was so easy to use, there wouldn't be all sorts of aiogram, python-telegram-bot, telebot and others.

And it is because they provide a lot of features besides autogenerated wrappers for each Bot API request.

@Aqendo
Copy link
Author

Aqendo commented Aug 23, 2023

Because it is impossible to upload files to a different datacenter.
I don't really think it's impossible. You can:

  • upload file to chat where inline query is being chosen
  • upload file to another chat and grab its file_id
  • upload file to the response of inline query

I don't know anything about Telegram's infrastructure, but this seems not true.

And it is because they provide a lot of features besides autogenerated wrappers for each Bot API request.

So? So you see that almost noone is using it as-is with raw requests. People are smart and wanna do the least possible with frameworks that allows them that. So, a lot of frameworks are being made and, back to the question, it's almost impossible to parse docs for automated codegen.

@levlam
Copy link
Contributor

levlam commented Aug 23, 2023

upload file to chat where inline query is being chosen

There is no such chat. It could be a secret chat between two users.

So you see that almost noone is using it as-is with raw requests.

Glad that you agree that machine-readable documentation for raw requests is useless.

@levlam levlam closed this as completed Dec 12, 2023
@Aqendo
Copy link
Author

Aqendo commented Dec 12, 2023

lol why closed

@levlam
Copy link
Contributor

levlam commented Dec 12, 2023

Because it was a question and it was answered.

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

2 participants