I'm considering using a message queue-like system as the backend for a web application that would provide for synchronization between a web server, mobile applications and browsers. Are there any existing turn-key SaaS solutions for this? This solution would preferably understand JSON.
I actually had a particular startup in mind when I asked this question, but I couldn't for the life of me remember the name of the company. But now I remember: Simperium
Additionally, Firebase is similar and perhaps more mature than Simperium.
Parse addresses a similar need (hosted backend) but it's RESTful so not addressing the same issue.
Related
I am planning to use Firebase database and want to know how it fits in to the following scenario.
lets say I have a browser app, android app / iOS which uses Web Services to get / insert data, web services talks to the Data Base and returns data to the client.
This way I have to write code once in my web services and all the clients use that to retrieve and insert data to the database.
If I want to use Firebase, will I be following the same approach of having webservices between the client's and the Firebase DB.
I have done some sample Firebase examples where it it gets data from database directly without web services and in this approach we have to write our logic on each client (Web browser/ android app/ iOs app).
I have looked into this article
https://firebase.googleblog.com/2013/03/where-does-firebase-fit-in-your-app.html?showComment=1480073224245#c464815735109872173
The Pattern 2 has the server concept but that does not look appropriate in my scenario.
Can I have my web service and Firebase database and get data Synchronization capabilities.
Correct me if I am wrong and please suggest the approach I need to take.
Thank you for your valuable suggestions in advance.
Thanks & regards,
Rao Burugula
The article you link gives you the most common options for integrating Firebase into your app. Pattern 2 is the easiest way to use the Firebase Database and run your own server-side code:
In this model the Firebase Database sits between the app on the user's device and your back-end code. By using this model, you can still get all the benefits of the realtime synchronization, security rules and scalability, but also have back-end code that runs in a trusted environment.
Of course you can also go for a more traditional three-tier model, where your app server sites between the devices and the database. But in that case the Firebase database won't have direct interaction with your app anymore, so you'll have to take care of the realtime aspects of the synchronization (if you want those) in your own code.
I also recommend reading the Google Cloud documentation on using the Firebase Database and App Engine's Flexible Environments. The architecture described there is the same, but a bit more up-to-date:
I am newbie here and confused by few things
Some websites (twitter, foursquare, etc) provide API to third-party developer to call. are those APIs the web services that the sites provide?
Are those web sites themselves built on top of those public APIs/web services? theoretically is it possible?
Comparing the traditionally built website and the websites build on top of web service, pros and cons? are there any performance, scalability, etc differences?
Thanks in advance!
I'm sure somebody can give you a more exact answer but reading your question and applying my self-taught knowledge:
The simple technical definition of Web Services according to W3C:
A Web service is a software system designed to support interoperable machine-to-machine interaction over a network.
http://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/
I like to think of web services as the interactive elements of a site that its customer base utilizes. For example, Twitter's web services include: tweeting, messages, hashtags, etc. Web services are what users get to DO or DATA passed back and forth.
A public web API provides means for developers to utilize the web services on their own site. For example, Twitter's API allows example.com site to utilize tweeting, messaging, hashtags, etc from within their own domain. An API is how developers get external access to web services to make apps using those services.
I have no idea about this question. I wouldn't do that. I would use the methods the public API exposes access to. But, I've never written my own API, let alone on the scale of Twitter or foursquare.
I hope this helps.
First of all, maybe you need some more info about what an API is: please take a look at the Wikipedia api page.
To answer to you questions (these are only general thoughts and not best practices):
An API, in this case, is a way that a developer uses to access a webservice, and it's not the service itself.
The websites you mention are not using their own APIs, as these APIs are meant for remote users (clients), and offer limited data sets, while the websites need maximum performance, access to the full database, and (almost) always use server-side code. The websites you mentioned, probably use other, server-side, high-performance APIs.
See the previous point: although it depends highly on which APIs you use, what you call "traditionally built websites" (that is, web applications using server-side APIs) can afford higher performance than websites totally built on top of remote APIs, because they do not depend on the bottleneck of the network connection (because, again usually, the web server and the database server either run on the same machine, or communicate faster than the client's browser and the server).
The reason that would make most people choose to develop a webapp the traditional way is that free APIs provide limited functionality (e.g. Google custom Search, limited to 100 reults).
We're setting up a website that schedules video-conferencing sessions for end-users (using our own technology). We're interested in providing access to this functionality to "corporate clients" to use through their own site.
Initially, we were thinking of having an API key given to each corporate client, and modules could be built in any language to fetch the data from our site. However, our requirements are changing and we're exploring how the data should still be visible to the user of the 'corporate client' even if a network disconnection takes place between their server and ours.
What are the mechanisms by which a website can provide access to its data / functions to other websites?
I would suggest, REST. REST is a lightweight software architecture designed to facilitate access to resources over HTTP/HTTPS.
REST constraints state that there is a separation of components and language agnostic interfaces among others, so your clients won't have to worry about using Java because you're using Java, for example. Aditionally, REST web services are supposed to be cacheable, which may help fit your desire to avoid network issues.
You can learn more about REST here:
http://en.wikipedia.org/wiki/Representational_State_Transfer
We have web service running for one of our projects. We want to be able to access this web service similar to how you'd access an API (such as Google Data, etc.) where you have client libraries in several languages: .NET, Java, Python, etc.
You'd be able to download these libraries (usually .DLL) from our project's website and then integrate these into your custom application.
The reason we want to have these client libraries is so that we can encrypt certain data transfers between the client and the web service and so that you wouldn't have to login a million times when you want to make a request (like you have to do when using raw SOAP requests).
So, my question is... What's the best way to do this? What would the client libraries contain, other than some encryption and a bunch of methods? What's the best way to create these libraries? Obviously some different platforms are needed to accomplish this (some flavor of Linux, maybe Mac OS), should virtual environments be used?
What are your thoughts? Thanks in advance for your help!
You would first express an API via the web service. What you are then interested in doing is creating a client "wrapper" for your web service API. This is what the client would download and use in their application (similar to Facebook.NET). This would be an assembly project and house a bunch of classes and so on. These classes would maintain the state of the program utilizing the API and would take care of all the low level plumbing work interacting with the web services by exposing a verbose object model that is easy enough for the user of your wrapper to get around in.
You could do this for any language that could interact with your web services. Java, Python, etc. I suggest using WCF though as you can use TCP for the .NET library and standard web services for the other languages. This will help you to be more performance oriented where possible.
I'm going to be developing a REST-ful Web Service for a new public website. The idea behind the web service is to have 3rd parties develop fully functional UIs for the business logic.
For security reasons, I'd like to avoid users having to give their passwords for our service to the 3rd party applications. (Perhaps this shouldn't be a big concern?) Instead, I'm looking to implement some sort of login system on our site that provides an auth token to the 3rd party app but keeps the actual password out of their hands.
This made me think that OpenID might be a potential solution here. It seems to me that it should work: the actual password is handled by the OpenID provider and so it doesn't rest with the 3rd party app. I think that the trouble would probably lie with the various passthroughs, but that should be manageable.
However, there's a surprising lack of Googleable info on this, so I'd like SO's opinion. Has anyone implemented a similar system before? Is it even possible? Is it worth the trouble?
I agree completely that what you want is OAuth; I say that having worked on both OAuth and OpenID systems. I've also been in your boat a few times, having to develop a REST web service api.
For a really good ideas on OAuth, and why it is what you want see these attached article:
These are must read, there are four parts read them all:
http://hueniverse.com/oauth/guide/
the RFC, read after reading above as it can be a little daunting for most:
http://oauth.net/core/1.0
And then finally maybe some code. I have a couple projects hosted that are using Java/Groovy to do OAuth. One is a plain old OAuth client, the other is a client for specific interactions with NetFlix.
http://www.blueleftistconstructor.com/projects/
If you are relatively inexperienced with REST (you haven't built a full scale web api yet) I would recommend that you buy (or better get your boss to) "RESTful Web Services" by Richardson & Ruby. It is an O'Reilly book. I can say that it is one of their better books to debut in the past few years.
It might also help to look at some RESTful OAuth based APIs. The NetFlix API is a perfect example: http://developer.netflix.com/docs
Good luck and happy coding!
So far, I've found 1 worthwhile link:
http://markmail.org/message/utf7js473zqv45hv
This conversation mentions something called "OpenID Exchange" which is right up my alley... but the included link is broken and there's not much solid information on Google for it.
Looks like OAuth might be the ticket: http://oauth.net/
We have been working on a project to integrate OpenID Authentication for SOAP web services. You can find our project at http://code.google.com/p/ws-sandhana/.
You can provide Single Sing On to your web services using OpenID authentication and you can enforce the trusted OpenID Providers and required attributes of the users by defining service security policies.
This is an open source implementation on Apache Rampart which is the security module for Apache Axis2 web service engine. You can find our blog at http://sandhana-project.blogspot.com/ for more information.