I am playing with my modem and some Azure mobile service. Last time with Azure I have up (2 years ago) but I decided to give it another go.
Looks promising, as it support HTTP and my modem does not support HTTPS.
The article is full of spelling mistakes and strange sentences and missing information so I am afraid there is a detail missing…
But trying the example I just get “code 302 Redirect”
I am simply sending the string with my app-id to port 80 on the azure server…
@ njbuch - Are you including the X-ZUMO-APPLICATION header?
In order to call the mobile service via the REST API, you need to either authenticate, or send that header with the value of your application key. Keep in mind that if you send that over HTTP (no SSL), you are essentially sending the keys to the kingdom in the clear, so I would not recommend this for anything you care about.
You might also want to check out the Azure Mobile Services REST API documentation here:
And the main mobile services docs here:
http://azure.microsoft.com/en-us/documentation/services/mobile-services/
Yes, indeed. I have looked at the documentation, but no-one is really adressing this issue.
Below is the raw string sent to port 80 on the host specified.
POST /tables/door/ HTTP/1.1
X-ZUMO-APPLICATION: .....MY KEY WAS HERE.....
Host: myhostnamewashere.scm.azure-mobile.net
Content-Length: 88
Connection: close
{"sensorID":22, "channel":5, "instSpeed":12,"averSpeed":5,"direction":2,"batterylife":90}
@ njbuch - Sorry, I’m not clear on which “issue” you mean?
If you’re having trouble accessing the Mobile Service from your device, I would suggest testing using the Fiddler web debugger. If you don’t have it, it can be downloaded for free from:
With Fiddler, you can use the Compose tab on the right-hand side of the UI to create the HTTP request and specify headers and values, etc., and then use the Inspectors tab to review the response. I find it an invaluable tool when testing HTTP APIs.
If this is just a test service, feel free to message me the URI and key info and I can test on my end.
I just tested a demo service I have running, and was able to make a GET request through Fiddler, once I sent the X-ZUMO-APPLICATION header.
@ njbuch - Sorry, just noticed you’re doing a POST.
When I do a POST to the service I have running, I get back a 201 response, and the response includes the location of the newly-created record.
Not sure why you’d get a 302. Did you make any modifications to the service? Or is it just a stock mobile service with the ToDoItem table?
Are you using a JavaScript backend or .NET?
Thanks for looking into this. I have tried using Fiddler AND putty with the string.
The issue I am having is that POST request sent to the server returns a “Redirect 302” and does not in any way do all the table-creating magic that the linked article claims azure would do for me. See link in first post.
BTW another question, I cannot enable logging of HTTP calls on the Azure mobile service configuration, that should be possible I think…
@ njbuch - One other thing…looking at your example, you may need to send the Content-Type header, with the value set to “Application/JSON”.
@ njbuch - If you’ve tested with Fiddler and are getting the same results as on your device, then the next step I’d try is creating a fresh mobile service just for purposes of seeing if a new service works through Fiddler and through your device. Then you can start working your way through what’s different between the two.
At least that’s what I’d do if I were in your shoes. 
No change trying all that stuff out. But thanks for assisting…
Giving Fiddler the option to follow redirects and enable HTTPS I now get an authorization error, wondering why… the POST is redirected to a GET.
I also tried user the master-key at the same time…no luck.
So: I am looking for examples of tutorials that shows how the “Azure mobile service” is working with pure HTTP. (And preferably something which is up to date, and without lots of errors and missing info…)
@ njbuch - Are you behind a firewall? Or something else that might be interfering with the request?
Given that I’m able to access an Azure Mobile Service just fine via plain HTTP GET/POST, I really don’t think this is an issue of whether or not that is possible.
If a brand-new Mobile Service exhibits the same behavior, then I’d start wondering if there’s an intervening device that’s messing with the request somehow (firewall, router, etc.). You said you’re doing this over a modem, correct? Is it possible that there’s something the carrier is doing that could be the cause?
I tried a clean and new mobile service…
As I am using both putty and Fiddler with same result I dont see where the request should be altered…and why…
Can you confirm that a new mobile service, where you send a http post request with some json in it to port 80, will create the needed tables as mentioned in the article. And that works for you?`
@ njbuch - Yes, it does.
Have you tried it without the modem? Or from a different network entirely?
Just trying to walk through the typical troubleshooting steps. Isolate all of the major pieces in the puzzle one-by-one.
Maybe you could post an end-to-end description of the hardware you’re using to test?
This is a cellular modem you’re talking about, yes? Or are you using a different kind of modem.
I am using Fiddler and putty from a win8.1 machine. No modems or exotic hw will be used until azure behaves.
@ njbuch - Not sure what else to suggest at this point.
Something must be different between your environment and mine, given that it works for me, but not for you.
Could location be a factor? I’m in the U.S., and typically provision my stuff in the US East data center.
Have you tried a different data center?
@ njbuch - When you get back the 302 redirect, where is it redirecting you to? On our sites at work we use redirects all over the place to redirect to other pages within our site, for example to redirect to an error page.
I SOLVED the problem.
Two things:
What my problems was:
When you create a mobile service it asks for “backend” I was expecting to choose .NET and not Javascript - .NET means: “You are managing your service from Visual Studio” (I think) but Javascript means you are managing the service from the Azure portal.
Secondly, people keeps writing that you can just post, and the portal will create the database and related structure - IT DOES NOT. You need to create a table, it will automatically create related columns for you. (which makes sense, but still…)
So, step 2 follows. 
@ njbuch - Glad you got it working.
To clarify on the behavior of Azure Mobile Services in terms of creating the database:
You are correct that in a JavaScript backend Mobile Service, you have to first create a table in order to post data to the service. Once you’ve created the table, as long as the Mobile Service is configured with the Dynamic Schema option enabled (see attached image), when you post data to the table using either the client APIs, or HTTP, the service will automatically add columns for any property that isn’t already in the table. This is great for when your schema is evolving rapidly, but you do have to watch out for typos, as Mobile Services will happily create a “name” field and a “nome” field alongside it if you mistype.
A .NET backend Mobile Service leverages Entity Framework Code First, and will automatically generate a database and the appropriate schema based on your underlying POCOs (Plain Old CLR Objects) if it doesn’t exist already. Additionally, the .NET Backend Mobile Service is configured out of the box to clear the database schema when the model changes. Again, this is very useful in development, so you don’t need to worry about modifying the database by hand when your model objects change, but you should not leave that on in production, since it could result in data loss if you change the model.
The difference between these two behaviors is what had me confused. I’ve mostly been working with .NET backend Mobile Services recently, so it didn’t occur to me to check whether you’d created the table, or for that matter whether you were using JS backend.
Hopefully, this makes sense in terms of the difference between the two models.
Again, glad to hear you’ve got it working.
@ njbuch - So…it actually seems to get weirder.
I decided to try creating a new JavaScript backend mobile service, and try POSTing to a table that had not yet been created. What I got back in that case was a 404, which is actually what I’d expect, since the table did not exist.
Then I tried creating a table, and sending another POST request (via Fiddler, BTW), and this worked and added the columns and fields to the table, just as I’d expect, and returned a 201 response.
For giggles, I disabled Dynamic Schema for the service, and tried posting with a non-existent column name. That resulted in a 400 response code, and an error message htat correctly described the reason (trying to post to a non-existent column).
I then tried deleting the table, but that just gave me a 404 response again.
I’ve not been able to replicate the 302 response with a JavaScript backend at all. I’d love to figure out why it was doing that for your service.
Just so I’m sure I’m not missing something, were you POSTing to a table that had already been created? That is, did the “door” table exist in the service when you were getting the 302 code?
@ njbuch - Did you happen to have any authentication configured on the mobile service that you were using? If so, then the 302 would make sense, since the login process usually includes some redirects, and I found at least one forum post from a while back that seemed to indicate that if the authentication information wasn’t properly configured a POST might result in a redirect back to the same URI as a GET request.