whatsapp-http-api icon indicating copy to clipboard operation
whatsapp-http-api copied to clipboard

[BUG][NOWEB] - Wrong Return Type for POST /api/sendText

Open AliSot2000 opened this issue 7 months ago • 1 comments

Describe the bug

Sending a POST /api/sendText returns the same response as GET /api/sendText but the response doesn't match the provided model below.

Version

{
  "version": "2024.6.8",
  "engine": "NOWEB",
  "tier": "PLUS",
  "browser": "/usr/bin/chromium"
}

To Reproduce Steps to reproduce the behavior:

  1. Start a Docker
  2. Log into a Whatsapp Account and create a Session
  3. Go to 'http://localhost:3000/#/chatting/ChattingController_sendText Expand the documentation
  4. Send a Request like this:
{
  "chatId": "[email protected]",
  "text": "Hi there!",
  "session": "default"
}
  1. Observe the response is:
{
  "key": {
    "remoteJid": "[email protected]",
    "fromMe": true,
    "id": "3EB00EA4283A734B87CFEE"
  },
  "message": {
    "extendedTextMessage": {
      "text": "Hi there!"
    }
  },
  "messageTimestamp": "1719917825",
  "status": "PENDING"
}

which doesn't match the described response below in the Responses Section:

{
  "id": "[email protected]_AAAAAAAAAAAAAAAAAAAA",
  "timestamp": 1666943582,
  "from": "[email protected]",
  "fromMe": true,
  "to": "[email protected]",
  "participant": "string",
  "body": "string",
  "hasMedia": true,
  "ack": -1,
  "ackName": "string",
  "author": "string",
  "location": {
    "description": "string",
    "latitude": "string",
    "longitude": "string"
  },
  "vCards": [
    "string"
  ],
  "_data": {},
  "media": null
}

Expected behavior ~~Either add the correct Response Model to the Documentation or make the POST /api/sendText exclusively for Groups and not single chats.~~ Looking more closely at all the errors generated, it seems to be an issue of NoWeb. The solution I see at the moment is, that the openapi.json file needs to be changed with the backend. Additionally, As mentioned here the errors also need some more attention, both to add them to the documentation as well as ensuring they have a consistent format.

It is also strange to me why the POST /api/sendText and GET /api/sendText exist. Get would Indicate the request is cachable which definitely is not the case. ~~It would make more sense to update the json response to have an indication whether the response is from a group message or a private message and allow parsing like that.~~

So my suggested course of action would be to Remove the GET /api/sendText endpoint and improve the documentation or even structure of the POST /api/sendText

EDIT: After testing the POST /api/sendText with a group as well as GET /api/sendText with a Group, they both return the same structured data and both return not the specified response model that is indicated in POST /api/sendText

AliSot2000 avatar Jul 02 '24 11:07 AliSot2000