Am I confused as to what is possible between an Android Client and Google App Engine? I would like to be able to create a Python API that would handle requests between GAE services such as Datastore, and an Android Client.
I have found some examples that detail how to make a call from within an Android Client, but it doesn't seem to outline whether or not you can pass data to any specific API language. The question I have is whether or not it is possible to use a Python API deployed on GAE and making calls through Google End Points, or would I have to use Java Servlets to handle requests?
Yes, you can use Python to do what you want.
Google designs their services (such as GAE and endpoints) to be language agnostic, e.g. using JSON to serialize objects.
There are a few advantages to using Java on both, such as being able to share code between client and service projects, but Google does not promote such dependencies at all - you will have no problem using Python instead.
Related
Application insights can used to monitor custom application events (such as calls, exceptions, durations etc).
The documentation gives SDKs for .net, and an agent for java. https://learn.microsoft.com/en-us/azure/azure-monitor/app/platforms
We are using java, but its hosting by Adobe (its their cloud CMS called AEM), so we cant run or install any agent. We can include java libraries, and cam make rest calls going out.
The question is, does AI have any sort of rest API to get application monitoring data into AI? Azure as a whole has one (e.g. for querying resource groups) https://learn.microsoft.com/en-us/rest/api/azure/
NOTE: this is not to query AI data, there is a specific API for that, we need an API to write the event and telemetry data into it.
I don't think it is officially published (REST API for ingestion).
At the same time the wire protocol is used by both all SDKs and by many customers who decided to use REST API directly. So, essentially REST API will not change.
One way is to build an app using agent, sniff wire protocol using Fiddler (or similar tool) and then use it as REST API.
Beware that Application Insights SDKs (and agents) take care of many things - starting from auto collection, calculating standard metrics and finishing with proper backoff logic/retries/etc.
On top of it Application Insights SDKs support two channels - Standard and Real-time (Live Metrics/Diagnostics). Implementing the second channel might be quite tricky.
I am creating a web application with a Java back end. I intend to house this on Amazon Web Services.
Ideally, in the future, I would like to create a Native Android application that carries the same functionality as the web app.
How can I implement my current application so that the Native App and Web App can both use the same back end database and services?
I have been reading about Service Orientated Architecture, is this the correct approach?
Service Orientated Architecture (SOA) is an approach that has been around for a while and could certainly meet your requirements. However I would caution you that you are going to run into lots of "Enterprise" designs as you search for information about SOA that will really be overkill for the type of development you are doing.
In general I would simply recommend that you focus on the following:
Keep your UI (HTML/JS/CSS) in a separate project from the Java back end. This practice will force you to keep the UI and back end concerns separate.
Have your back end expose an API that sends and receives JSON via HTTP/HTTPS.
Make your back end services stateless. Using JSON web tokens for authentication is a good way to accomplish this (I like using Auth0 for this). In other words don't rely on an HTTP session to track your users from within your Java code. This has the added benefit of making your application really easy to scale.
If you do these things then when it comes time to build the Android app you wont have to touch the back end at all. You will just have to implement the UI again in native Android.
Since you tagged this question with AWS I assume you plan to implement your back end on AWS. If so, I would highly recommend you look into using Amazon's API Gateway service. This service would sit between your UI layer and your back end. This provides several advantages such as rate limiting and caching to secure your API from DDOS attacks, an optional API key for added security, and API versioning to help you deploy new versions of your API without breaking existing clients. Also, by defining your API using the API Gateway service you can then generate an SDK for your API for use in JavaScript, Android and iOS.
Another big advantage of using API Gateway is that it allows you to break up your back end into separate servers, Lambda functions, etc. This allows for great flexibility, and I can't stress enough how the ability to use AWS Lambda in your back end will reduce administrative work as well as hosting costs. This enables you to start thinking about your back end in terms of Microservices.
I am very new to both Android development & Azure Mobile Services. I have a decent knowledge of Java so Android development is not proving to be too difficult. Although, I am struggling to gain a good knowledge of working with Azure Mobile Services.
I have little knowledge of REST API's but will be able to learn quite quickly if required. My main concerns/questions are as followed:
Can I build my Android app by using Mobile Services Data & API's alone. i.e the simple table values and the basic CRUD API's?
If not, how should I approach building the application?
I want to cater for multiple column queries, table relationships (1 .. n , inheritance) and I also would like to use JSON objects as parameters for a more lightweight communication rather than passing my full Java objects.
Also, is the possibility of setting up an SSL available?
Any help would be appreciated.
thanks for trying out Azure Mobile Services. Here is a good tutorial on how to get started with Android.
To answer your questions specifically:
Generally a CRUD API for data storage and a custom API for arbitrary REST calls should be all you need for a straightforward app, and those are all offered in the box with Mobile Services. The one thing we don't offer today (but are considering) is support for duplex messaging (WebSocket), which you might need if you are building a realtime app or game.
Mobile Services does not support object trees on the client, but you can still have them in your server database. You just have to write some custom code to "flatten" the hierarchy before you send it to the client.
Every mobile service supports HTTPS by default. We do not currently allow you to do a custom SSL cert.
I was looking for some opinions on the best remote method invocation practices when developing iPhone applications that communicate with Java (java EE) servers.
Many iphone applications these days typically talk to a server back end. I typically prefer to write my servers in java using some Spring libraries. So far I have not found or stuck to a definitive practice for iphone->java server communication.
What are some technical solutions and libraries that you have used to implement this kind of client-server communication?
One thing I always keep in mind is that I want the communication protocols to be simple so that multiple platforms can be added for example, in future adding Android and possibly Blackberry clients, that can use the same protocol to talk to the server.
I'd go with JSON. If you want to use Spring, go with restful webservices. Do some googling on "webservices restful spring json" (without the quotes) and you'll get some pointers.
JSON will suit you fine with other languages as well. I've written an iPhone application that uses JSON, and that was quite easy with the use of
http://code.google.com/p/json-framework. I'm pretty sure that both Android and Blackberry should be capable of reading JSON just fine as well.
Edit: I forgot to mention that I have put this iPhone application under an MIT license and you can browse the code on google code:
http://code.google.com/p/accountadmin/source/browse/#svn%2Ftrunk%2Fiphone%2FFrittRegnskap%2FClasses
I'm currently doing this for work as well. Our backend is Java EE (with Spring) and then of course the front end is iOS. We use JSON as the payload format, as Knubo suggested. All of our web services are also RESTful to make dealing with URL construction and authentication on the phone easier.
I would highly recommend you check out RestKit, which is a pretty comprehensive framework that allows you to easily integrate your RESTful, JSON-based web services with CoreData. We also use YAJL for parsing JSON manually in the rare cases where that is necessary.
Thus far, that tooling has made it a breeze to work with our web services.
http://code.google.com/p/json-framework is really useful.
As per my knowledge api and web services are used to fetch data from other websites.
So what's difference between them ?
Any Help!
EDIT
Can somebody please explain it with proper example ?
What is twitter and facebook api ? Can we say it's just a function or webservices to access their data.
A web service is just an API in HTTP clothing.
A web service is something delivered over the Internet for direct use by another computer (rather than a human).
An API is an Application Programming Interface. A website application might expose an API thorugh a web service. However, desktop applications like Excel or Word have APIs which have nothing to do with the web (they have VBA and COM based APIs).
Simlarly, a server application (eg. Joomla) might have a PHP based API that is used from withinthe server - ie. no web service necessarily involved.
All web services are APIs, but not all APIs are web services. One is a subset of the other.
Web Service is an API wrapped in HTTP.
All Web Services are API but APIs are not Web Services.
Web Service might not perform all the operations that an API would perform.
A Web Service needs a network while an API doesn't need a network for its operation.
An API doesn't need to be web based.
Web Services may also may not perform all of the operations one would expect from a full API.
API (application programming interface) is a list of methods and classes exposed by a programmer to use by other programmers, so eg if you use Twitter or Facebook API in your programs, you can make it cooperate with Twitter and Facebook, and do many useful things. :-)
There are many ways of exposing APIs (JAR files or RMI in Java, .net Assemblies, COM objects, DLL and .H files in C/C++, JSON over HTTP, XML over HTTP, many home-made methods).
Web Services are just yet another way of exposing API, in this case the actual execution of the exposed methods is done not on your computer, but on some other computer on the Internet (on the Web - hence name "WebServices").
A web service can be thought of as a type of API. But for the moment, you should forget that, and just concentrate on learning what an API actually is; a precise definition of methods for interacting with a piece of software. Sometimes, this involved sending data over a network, but usually we're talking about functions that may be called from a program.
For example, there's a function called FileUtils.rm in Ruby. This is the API; when you're calling the function from a Ruby script, it always looks the same. Then there's the implementation of the API; that's the code that actually removes the file - it might look completely different in every implementation of Ruby, but you (normally) don't care about that, since you're only dealing with the Ruby API.
Webservices available over internet.you can get information without actually having the classes or know how it works using http and soap protocols.
API is a kind of library (set of classes), you can use the functions available in that to perform some action in your application.
Check out the wikipedia entry on web API's at http://en.wikipedia.org/wiki/Api#Web_APIs.
It's well written, though pretty much agrees with what the others here say.
APIs exposed over web are Webservices