[Steve van der Burg]

That’s only bad if they’re being passed in the clear. As long as the requests and responses are encrypted in transit, you’re fine.

It’s not like I’m describing something unique or new or odd — every other REST API works that way.

[Steve van der Burg]

I’m not saying that the REST calls shouldn’t be associated with a user. I’m saying that requiring a “log in” REST call that then ties the logged-in user to an IP address is wrong. REST is supposed to be stateless, so I should be able to submit credentials with any REST call and have it work.

But tying a user to an address and not supplying a unique ID for a message submitted for sending (so that its status can be reliably looked up later) are the real deal breakers for us. We’ve tried for a year, but we are unable to build a reliable service on top of these modems because of those issues.

…Steve

[Steve van der Burg]

I see now that there’s version 4.1.0 of the firmware out. I had to guess at the URL of its change log (based on the 4.0.5 one that you gave me) and in it I see this:

– Certain version 1 API (/api/v1) calls do not work.

That’s a pretty scary line to come across. Can you refer me to documentation for the API version that 4.1.0 uses? I can’t seem to find that anywhere either.

And it looks like the same basic issues still exist:

– A misunderstanding of how REST should work. It should be stateless, and not have a notion of “logging in” or “logging out”. And it certainly shouldn’t tie a user to a connecting IP address.
– The API for SMS send should return a unique identifier for each request, and another call should return status on the message with that identifier.

Do you know if any development work is going on that would address either of these?

Thanks,

…Steve

[Steve van der Burg]

Doing that now.

Thanks,
…Steve

[Steve van der Burg]

Okay, thanks for clarifying. I’m using 3.7.3.

Although we’re in production with 4 rcell modems now, and sending about 1800 SMS messages a day in total across those modems, I’m really not happy with my inability to build a useful, robust service using interactions with, and information from, the REST API.

I’ve also seen a lot of buggy behavior that has led to missing SMS messages. Just yesterday, a modem failed to send an SMS and then failed to send each message after that (for 2 hours). Once I rebooted the modem it then was able to send every “failed” message except the first one.

Aside from bugs, my first issue has to do with the modem API’s inability to tell me whether “failed” means “failed to hand the SMS off to the provider (that the modem’s SIM belongs to)” or “provider told me that this message can’t be sent (in the case of a phone number that can’t be messaged)”.

The second and HUGE issue is the inability to track a message. When I submit an SMS request to the modem I should get its GUID back in the response. That would give me a way to poll the sent box and tie outcomes for messages there to messages that I have sent.

When polling the sent box, each message’s status should include the number of retries attempted so far (not the “retries” setting, which is what it seems to return now). Also, I’d like documentation on the retry schedule (eg. does the modem retry all ‘failed’ messages that haven’t hit the retry limit once per minute, does it back off and try less and less frequently per failed message, etc).

[Steve van der Burg]

Thanks so much for all of your help so far. I have another question now about the sms_send REST endpoint. I see that it can take a list of recipients (numbers).

Any idea if there’s a limit on the size of that list? If I want to put 1000 numbers in there, will the modem send them?

And do we have any idea at what rate?

And will the modem queue additional requests while it’s completing a large one (like my “send to 1000 numbers” example)?

I really can’t bother 1000 people by testing some of this stuff out, so if the developers have information on some or all of it, it would help me out greatly.

Thanks again,
…Steve

[Steve van der Burg]

Actually, before I upgrade one of my modems, I would really like clarification on some of your statements. I read the 4.0.5 and it doesn’t mention multiple users or concurrent sessions anywhere. After reading it, it seems that I’ll be able to name my single user “bob” instead of “admin”, but my plan here would be to create 3 users (“prod”,”dev”,”demo”) and have each tied to a different host, with all 3 simultaneously logged in.

Maybe somebody already using 4.0.5 can confirm that this is possible?

[Steve van der Burg]

That looks like it. Thanks for your help!

[Steve van der Burg]

That sounds good, but so far I can’t even tell which (if any) of the files in the downloads area corresponds to MTR 4.0.5. It’s firmware for a Mulitconnect rCell 100 that I need. The firmware update tab in the web UI says “MTR-LAT1 Firmware3.7.3” is currently installed.

For that matter, which forum here corresponds to my hardware? None of the names clearly match the product.

Any help would be appreciated.

[Steve van der Burg]

Is there any news on this?

[Steve van der Burg]

Gmail is built for users (ie. people) to hit via their web browsers. The use case is completely different than that of a REST service!

I’m looking forward to multiple user support, but I think you should seriously consider dropping the “tie a user to an IP address” restriction. It adds nothing to the product and adds complications to anyone developing for it.

[Author]

Posts