@ 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:
@ 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.
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 - 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?
@ 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.
DONT think that the articles you read are up-to-date and can be followed down to the small details, and dont think you understand the names of the configuration options!
KEEP trying creating new services until you have tried all options and it works
What my problems was:
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…)
To clarify on the behavior of Azure Mobile Services in terms of creating the database:
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.
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.
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.