Here is my scenario: I have an iPhone app (written in Monotouch but that has nothing to do with the design) that has consumables. I give 25 free consumables when the app is installed. If the user deletes the app and re-installs it, he now gets the same 25 free consumables. I need a way to prevent this.
So I came up with the idea of a database on a server (my website host?), which would have a list of UDIDs. If the user's UDID is in the database (that means he has already installed the app) a response is sent back to the app to set the consumable count to zero. If the UDID is not in the d/b, then it is added and the response is so indicated (new app).
I am thinking of using REST (simpler) and a Linux host for the server side. My questions are:
Is there a better way of doing this?
What is the language of choice on the server?
What about sqlREST? (looks very good to me, but will it work in the above scenario?)
Well, I can tell you what MY language of choice would be: ASP.NET/C# in combination with an SQL Server DB. I have my website running at a hoster which offers this combination for just a few bucks per month.
You don't even need webservices. You could just setup an ASPX page on your server and call it using NSString.FromUrl (or whatever the method is called): "mycounter.aspx?udid=1234". Everytime the page gets called, it increases the count of the passed in device ID and the only thing it ever outputs is the number of remaining requests.
Your client parses that response to integer and if it is zero, informs the user.
You should proably add some hashing to make sure that evil Krumelur won't go to your URL and call it for random device IDs, rendering them unusable. :-)
René
The answer really depends on your web host. And what they support. That probably depends on your transaction volume and so on.
Since you are using Monotouch I'm going to assume you are comfortable in .net/c# world.
I would look at a WCF web service written in c#. This in turn would use SQL server for storage. Of course you could just go straight to a SQL server stored procedure.
sqlREST looks interesting but at a glance it looks like you need to be running the Appache + Tomcat stack for that to work.
if you just want the lowest possible bar to get it working then I agree with the other poster... ASP.NET + SQL server would get it done too.
Related
I've been assigned a small project and directed to use Mirth Connect as part of the solution. We currently do not use Mirth but because we have an upcoming project that will require an interface engine, I was asked to use it for this project so I can gain experience with it. However, I think it's a poor suggestion for this project; I also know my boss would not want me to implement something that adds unnecessary complexity just for the sake of learning.
With that said, I want to make sure I have valid reasons for suggesting that Mirth Connect should not be used for this project. Neither of us know much about it, but I think he's been convinced it is the end all solution for all things interface/webservice related. I appreciate any input I can get from those of you who have more experience with the product than I have.
This is a very simple project in that we have a client needing to make a handful of requests into our system from there's in order to retrieve and update data. For example, they will make a request to get patient demographics, to add an admission for a patient, a request to get a list of possible care settings from our application, etc. For this project we will not use HL7 but a set of predefined XML messages.
Both the client's application and our application reside on the client's network.
They do not want to build any services of their own, so the services we build need to handle all of the work. The results returned in response to their calls to the services will be returned as XML.
There are no plans to integrate any other applications with theirs or ours in the foreseeable future.
It seems to me the best option would be for us to build a standalone web service that would take their request and send back an XML response. I just don't see any reason to include Mirth Connect in the picture (other than for learning but that can be gained in other ways).
What are your thoughts? Is it true that the interface engine is not a good choice if the client wants to receive data from our system without having a receiving mechanism on their end? In other words, they want to make a web service call such as GetCareSettings and to get a response back with an XML representation of all the possible care settings in our system. It seems to me they would need a web service on their end for Mirth to use as a destination to send the results. All Mirth is going to send back is an ACK message, correct? (Unless of course it wrote the data to another webservice on the client end, which they have said they do not want to do.)
Thanks for taking the time to read this. I hope my lack of knowledge and understanding of Mirth Connect and the use of interface engines hasn't made this question difficult to answer.
From what I understand, Your client appears to be either a Lab or a third party service vendor, who will take inputs from your application like patient demographic charts, appointments, provider details etc. Basically he wants to query your application.
A) HL7: It has the capacity to handle query request and response with demographics. I am assuming that you have done you might be knowing about QRY messages.
B) XML/webservices/SOAP:still provides a viable solution, a little more concrete and can be expanded to Handle custom request like GetCallSettings, or may be any other. The vendor is not just interested in fetching patient related data but also other inputs for which HL7 might not be enough.
If we talk about approach, then its a professional advice to use an interface engine. It is not limited to just using mirth connect, you can also use Iguana if you want. A good reason which comes instantly to my mind is that an engine gives you an advantage while troubleshooting, support and maintenance activity.
Your Webservice responses can be handled easily by HTTP sender connector type and through RESTful webservices.
The engine is also capable of handling large volumes of request and responses at the same time, which in case is not required right now, but I think will be the condition later on. Your source in the channel shall change to an Webservice Listener.
Another good approach is to do away with XML and use JSON for handling request and responses, a much more light weighted than XML, to save your overhead with the network. We are doing some similar work, but we are sending request to a webservice through JSON.
Overall, Mirth is there to make your life more easier.
Good Luck!
When developing apps, your server and your iPhone evolve and not always back-compatibility is possible.
I guess adding a protocol version number in every request should do the trick (instead of, let's say another web service for protocol version).
Amazon do it in every request (here a sample):
https://forums.aws.amazon.com/message.jspa?messageID=269876
So, when the app is too old for the current protocol, it shows a message blocking the app and asking the users for an update. Otherwise, customers with an old app will see an app that doesn't work very well. That's not good.
My question is: How do you implement a similar versioning schema into a JSON reply without interfering the parser, object mapping and entity mapping? Any suggestion?
Perhaps there is another schema like passing an app version in the headers every request, and if error, the server returns and error message like (from twitter):
{"errors":[{"message":"Sorry, that page does not exist","code":34}]}
I'd like to know how do you solve this problem.
Regards.
You can version your API using the media-type. For instance, if your media-type is application/vnd.ricardo+json and you need to make a change that is not backwards compatible, you would create an application/vnd.ricardo-v2+json media type.
New version of the app will Accept the application/vnd.ricardo-v2+json media-type and get the new content. Old versions of the app will continue to Accept the application/vnd.ricardo+json and will never see the incompatible change.
When you want to retire old versions of the app, simply have requests that only accept application/vnd.ricardo+json return 406 Not Acceptable. You can then use this in you app to trigger logic to prompt the user to upgrade.
If (for whatever reason) you need to allow the app to support multiple versions of the server you can have it Accept application/vnd.ricardo-v2+json, application/vnd.ricardo+json; q=0.5. In this situation, the server will respond with application/vnd.ricardo-v2+json content if it can and application/vnd.ricardo+json otherwise.
You could use this to give you greater control over the "release" of a new feature. For instance you could release and update for the app, use request statistics to determine when a sufficient number of users have upgraded. You can then co-ordinate releasing the new feature by flipping a feature toggle on your servers and doing a marketing effort at the same time.
I'm currently developing a mobile app using Sencha Touch 2 and Phonegap. It's a game where you can "check-in" at some places and get some points every time you do a successful one (as in Foursquare).
I'd like to make it impossible for a clever guy (for example, someone that has decompiled my apk) to execute the REST web service (for example, mywebservice/checkin?access_token=abcde&latitude=12345&longitude=6789) with his computer or any other device outside of the app.
Do you have any idea of how I could achieve this ?
Thanks a lot,
In absolute terms, what you are looking for is impossible - if the app on the device contains the key and code necessary to send a valid message, and the device allows the user to decompile apps, then anyone can theoretically reverse engineer it and send whatever messages they want.
In practical terms though, it isn't worth worrying about - nobody will put that much effort into it, and you can probably detect accounts with suspicious activity fairly easily. Just use https and a simple token from the app code to stop anyone who can see the network activity but won't go as far as digging into the app code.
Couple options (depending on your exact scenario):
Bake user info and the app key into the security API key. This would ensure only valid account holders can use the API. Take a look at OAuth
Monitor per account or per connection service activity and look for any suspicious patterns. For example, if the app is operating in user think time then you would expect low numbers of calls per second.
I need a little help solving an issue regarding .NET web services. I have a desktop application that consumes my main web service. One of the methods gets some report data, but in order to do that, web service (A) calls a method in web service (B). Depending what parameters I pass into "A"s method, it either works or fails. If I pass in a filter, the dataset is pretty small, when I don't pass in a filter obviously the dataset is very large. Additionally, if I run web service "A" in debug mode and point my desktop app to the local version (meanwhile B is on our production server), it works wether I filter the data or not. The error I get is a 502 Bad Gateway on production, and a 502 - Web server received an invalid response while acting as a gateway or proxy server.
We have a web farm with some ARR's, so I went into the web farm's ARR, and found "Proxy" settings and adjusted the timeout to 1200 seconds (whereas my app usually fails within 20-30 seconds) and I'm still receive this error. The HTTP version is in "Pass through" mode with the "keep alive" checkbox checked.
We have no issues using a windows service consuming a web service or anything like that, just when one web service consumes another web service.
Addition,
I'm not using any sessions in my web service methods, and I believe the webmethod I call in web service "B" does have a cacheduration value set of 5 minutes.
I'm scratching my head on this for my lack of knowledge of IIS 7, and many other things. If anyone has any ideas or can point me in the right direction I would certainly appreciate it.
I thought I'd come here and answer this question in case anyone else ran into the same issue. This issue was not server related at all. It was code related. In my code I had a datatable (c#), and was doing a datatable.select(....) where I would pass in a filter with many "OR"'s. Ex. Filter = 'x' OR 'y' OR 'z' etc etc. I had around 100 of these, which caused the datatable.select method to produce a stackoverflow exception. I changed the code to do an "IN (x,y,z)" and it works fine now. Hope this helps someone.
I develop industrial client/server application (C++) with strong real time requirements.
I feel it is time to change the look of the client interface - which is developed in MFC - but I am wondering which would be the right choice.
If I go for a web client is there any way to exchange data between C++ and javascript other than AJAX <-> Web service <-> COM ?
Requirements for the web client are: Quick statuses refresh, user commands, tables
My team had to make that same decision a few months ago...
The cool thing about making it a web application would be that it would be very easy to modify later on. Even the user of the interface (with a little know-how) could modify it to suit his/her needs. Custom software becomes just that much easier.
We went with a web interface and ajax seems the way to go, it was quite responsive.
On the other hand, depending on how strong your real time requirements are, it might prove difficult. We had the challenge of plotting real time data through a browser, we ended up going with a firefox plugin to draw the plot. If you're simply trying to display real time text data, it shouldn't be as big an issue.
Run some tests for your specific application and see what it looks like.
Something else to consider, if you are having a web page be an interface to your server, keep in mind you will need to figure a way to update one client when another changes the state of the server if you plan on allowing multiple interfaces to your server.
I usually build my applications 2-folded :
Have the real heavy-duty application CLI-only. The protocol used is usually text-only based, composed of requests and answers.
Wrap a GUI around as another process that talks to the CLI back-end.
The web interface is then just another GUI to wrap around. It is also much easier to wrap a REST/JSON based API on the CLI interface (just automatically translate the messages).
The debugging is also quite easy to do, since you can just dump the requests between the 2 elements and reproduce the bugs much more easily.
Write an HTTP server in your server to handle the AJAX feedback. If you don't want to serve files, create your server on a non-standard port (eg. 8081) and use a regular web server for the actual web page delivery. Now have your AJAX engine communicate with the server on the Bizarro port instead of port 80.
But it's not that hard to write the file server part, also. If you do that, you also get to generate web pages on-the-fly with your data pre-filled, if you want.
Google Desktop Search does this now. When I search my desktop for 'foobar', the URL that opens is this:
http://127.0.0.1:4664/search?q=foobar&flags=68&num=10
In this case, the 4664 is the Bizarro port. (GoogleDesktop serves all the data here; it only uses the Bizarro port to avoid conflicts with any web server I might be running.)
You may want to consider where your data lives. If your application feeds a back-end database, you could write a web app leaving your c++ code in tact -- the web application would be independent and offer up pages to web users and talk directly to the database -- In this case you have as many options, and more, as you have indicated.