Hi there,
I’m trying to rest an endpoint on iOS via REST call and I get this error with the call:
Here’s our application ID: BBC4C8BE-6E60-4361-8559-EC9B388144C4 (even though it’s in the screenshot).
It’s so strange because the endpoint does exist and I’ve created and hit endpoints without getting this error code up until this point but I’m sure I’m missing something.
Happen to know what the issue could be?
Hello,
Unfortunately, the screenshot is not helpful.
Here’s what might help:
Regards,
Mark
Here are some of the details:
URL: https://api.backendless.com/BBC4C8BE-6E60-4361-8559-EC9B388144C4/A59FFD5D-61C4-4765-8F34-FA76F67BB903/services/MESSAGING/getMessagesByConversation
Method: GET
Parameters: {
conversationID: String = “0B35A826-17B6-4C29-B909-FDEB99DBCDCC”
offset: Int = 0
}
Parameter Encoder: JSON
Headers: “Accept” : “application/json”
That results in this:
Error Domain=BackendlessErrorDomain Code=0 “Request Failed → No Error Data” UserInfo={NSLocalizedDescription=Request Failed → No Error Data}
Hello @Innocent_Nwaukwa
Based on your description:
I made a cURL request:
curl -X "GET" "https://api.backendless.com/BBC4C8BE-6E60-4361-8559-EC9B388144C4/A59FFD5D-61C4-4765-8F34-FA76F67BB903/services/Messaging/getMessagesByConversation?conversationID=0B35A826-17B6-4C29-B909-FDEB99DBCDCC&offset=0" \
-H 'Content-Type: application/json' \
-H 'Accept: application/json'
which returned the following list:
[
{
"created": 1749607835511,
"___class": "Messages",
"body": "Test test test test test test test test test test test test test test ",
"ownerId": "0465AAA2-8266-4E8A-B665-C58354EE230E",
"updated": null,
"objectId": "D3604349-30B3-46CA-9D2A-7990F791AD19"
},
...
]
Are you still seeing a problem with your request? If so, please provide more details on how you are executing the request, via our console (API Services - Deployed Services - Messaging - Get Messages By Convo ID), using cURL, or some other way?
Regards,
Volodymyr
We’re using AlamoFire in XCode in Swift for iOS development.
We’ve foud that the issue only exists for newly created endpoints.
Already existing endpoints worked just fine.
For example: Testing/test works fine
However, Testing/getMessages fails despitet being structured the same way as far as I can tell.
And both are being called the exact same way but only one is acknowledged as existing with the AlamoFire calls.
Could you please describe steps to reproduce the issue, like:
Regards, Vlad
The issue occurs when the endpoint is called using AlamoFire for a brand new endpoint.
It works in this case:
It seems for some reason, newly created endpoints aren’t being called successfully.
I don’t know when it started as we hadn’t the need for new endpoints for a few months but now we do.
Thisis a sample of how we invoke the call:
let exp = expectation(description: “Fetch Lobby Users’ Locations”)
DB.SERVICES.LYNQ.RETRIEVE_LOCS.invoke(parameters: lobbyId, callback: { response in
switch response {
case .success(let lobby_points):
// expect 2, non-nil values
// dummy assert
case .error(_):
// dummy assert
}
exp.fulfill()
})
I am not familiar with the AlamoFire, and we do not provide support for 3rd party libs, so if you’ve got any issue with the module would be better to ask on their community, perhaps you compose the request in wrong way.
Once you deploy a new service/method it becomes available immediately, on the API Service screen you can select the method and invoke it, also there is the ability to copy cURL for running the method. You can prepare the cURL for new method and run right after deploying the service.
But, if you do not see the new method in the list please let us know
If we had ever had issues with calling endpoints from the beginning, I’d be inclined to agree with you, but we haven’t had this issue before and it’s consistently only existent with newly created endpoints. The method with which we use to call endpoints works just fine. What I’m having an issue with is what the supposed difference seems to be between old and new endpoints that’s causing this issue because it’s consistently replicable.
I’ll still give the example of the Testing/test endpoint. That works fine. But Testing/get messages doesn’t.
That’s not indicative of an invoke error but rather a backend config error. Something is different between the new and old endings and I won’t know what it is which is why I reached out. I don’t know if I’m missing something myself that doesn’t expose the new endpoints as the old ones are.
If the issue was AlamoFirs, we should’ve had this issue from the start or it should exist with all endpoints right now but that’s not the case.
Are you asking if I include a space in the request?
As in /Get Messages instead of /getmessages?
yes
Definitely not. You can look to the other endpoints created in other services as well. I always go with the actual endpoint URL.
Could you please share the code that makes the request to Testing/getMessages, since code you shared above hasn’t any references to our service
I provided dummy code in the same format.
That’s the code we use, you’d pretty much just be swapping out LYNQ for TESTING and RETRIEVE_LOCS for GET_MESSAGES as those are variables to represent the actual strings.
I would love to assist you and solve the issue, however, since the method is persisted in your app and it can be running using cURL (which means the method is available for running using REST) it seems like you need to debug your code which is out of our control
Was mainly reaching out for insight on differences between the old and new endpoints because that’s the only place we’re having issues. We’ve never seen this before.
But if the configuration seems to be the same for those two endpoints, it wouldn’t make sense that were suddenly getting issues for the newly created ones.
We’ll go back to the drawing board and see what we can do if they look the same on your end.
