Ways to embed a version protocol number in every request in REST? - web-services

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.

Related

How to properly notify client of changed status?

I am writing a (Django-based) website which is working just fine. It displays a list of sensors and their status. If a new sensor is attached, the user needs to wait for a certain amount of time until it is warmed up and ready to use. Also, when the sensors are updated (which the user can trigger, but can also be done automatically by the system) - the user needs to wait.
On the server side I have all signals/Status updates/whatsoever available. Now I want to create an overlay for the current webpage where the statuschange is displayed for x seconds and userinput is disabled.
I have no clue what technology to use. I could frequently ask for updates client -> server but that doesn't feel like the correct way. Any suggestions on what to search for?
No code here because the answer is probably independed of my website code
Standard solution is to use Ajax (JavaScript) or similar to get state from your backend on specific intervals, that is the approach you're mentioning.
You can also "push" changes from your backend to frontend using WebSockets but that is a bit more complex. A popular framework is socket.io, I recommend you take a look at it.

How to channel data thru Django's URL from third party URL without using redirecting?

What kind of existing options there is to make the client's GET "myserver://api/download/12345.jpg" to download from some_cloudfront_server://files/12345.jpg without redirecting the client to that CloudFront-path? Ie. I want the client see only myserver://api/download/12345.jpg all the time.
It should be some kind channeling solution, as downloading a full file first to Django-server and then sending it to the client is not applicable (takes so much time that the client will see timeout before a response to its query comes). Any existing libraries for this? If I have to create one myself, I welcome even just tips where to start from as Django's communication layer is not too familiar to me.
Problem here is that we are creating CloudFront signatures with wildcards to certain set of files, in format files/<object_id>*, thus allowing the client access only to certain object's all files in CloudFront-server directly. This works fine as long as file access traffic from clients is low. But if we start creating separate access signatures for hundred different files at same time, CloudFront starts throttling our requests. Solution I came up is to create and store to Django-server one generic allow-all signature for files/*, which is used only by Django-server and never given to any client, and then we let Django-server decide should it fetch files for the client or not. Thus, I can't give to the client the CloudFront-path with a allow-all signature, but I can channel CloudFront-data thru Django's endpoint to the client without showing signature to the client.
Environment I'm working with is Django v1.11, and Django REST Framework v3.4's ViewSets.
One colleague heard about my problem and mentioned that signatures can be made locally at server, thus no CloudFront connection needed every time the signature is created and we can keep signatures as file specific. He took this task for himself so I don't know details yet.

django-channels databinding on model.save()

I have a channels app that is using databinding. When changes are made with django admin they are being pushed to the web as expected. I have loop set up on a socket connection to do some long polling on a gpio unit and update the db, these changes are not being pushed to the web. Channels documentation says:
Signals are used to power outbound binding, so if you change the values of a model outside of Django (or use the .update() method on a QuerySet), the signals are not triggered and the change will not be sent out. You can trigger changes yourself, but you’ll need to source the events from the right place for your system.
How do I go about triggering these changes, as it happens with admin?
Thanks and please let me know if this is to vague.
The relevant low-level code is in lines 121-187 of channels/binding/base.py (at least in version 1.1.6). That's where the signals are received and processed. It involves a few different things, such as keeping track of which groups to send the messages to. So it's a little involved, but you can probably tease out how to do it, looking at that code.
The steps involved are basically:
Find the right groups for the client
Format your message in the same way that the databinding code would (see this section of the docs)
Send the message to all the relevant groups you found in step 1.
Alternatively, you might consider using a REST API such that the socket code submits a POST to the API (which would create a database record via the ORM in the normal way) rather than directly creating database records. Your signals will happen automatically in that case. djangorestframework (server-side) and requests (client-side, if you're using python for the long-polling code) are your friends if you want to go that way, for sure. If you're using another language for the long-polling client, there are many equivalent packages for REST API client work.
Good luck!

Is using Mirth Connect or any other interface engine overkill in this situation?

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!

I need some help with web services

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.