I have a website and i need to make an app on android and iphone and the app has to communicate with the server,similar to facebook app.Do i need web services like SOAP for this.I read their documentation but how necessary are they and what is their main purpose? Can I do the same without using web services? my website is in codeigniter
If you need to implement web services for your app, I recommend taking a look at CodeIgniter Rest Server. This provides an easy way to implement REST web services, which are lighter weight, easier to work with, and more flexibile than SOAP.
Benefits of using a Web Service:
1 - Usability: You can develop Android and iOS apps, and both of them can use the same Web Service. Other smart phone platforms can also be developed later and use the same Web Service.
2 - Flexibility: For instance, you need to have a mechanism to talk with the database. You can implement the database transaction in your Web Service. (I have experience in using hibernate) You do not have to create a database configuration in every smart phone app. If you decide to change your database, then you just need to modify your database configuration in the Web Service - nothing changes on the client sides.
3 - Security: It is not a good mechanism to connect directly from a Mobile app to your database server. You need to have some kind of Authentication mechanism that can be provided by a Web Service.
Which kind of Web Service is better? I agree with #Justin that REST is a good approach since it is lighter, simpler to implement and more flexible.
SOAP can be a better approach when Security is the most important thing, for instance in certain enterprise scenarios. REST vs. SOAP
Are webservices necessary? Well the correct answer to your question is it depends on the app. Most apps that connect to a server to get some information use web services. However, no you don't need to write your own web services. Increasingly people are using platforms like agigee
http://apigee.com/about/products/usergrid/
So no you would not need to write your own api if you used usergrid, but you might want to if you wanted to keep the data all within your own infrastructure.
Related
I already have an ASP MVC web application with authentication and authorization.
and now I am working on an android application which will perform almost the same thing as my web application does.
I can use my ASP MVC web application to return json data to my android application, but as I've searched a lot and I was suggested to use Web API for android application.
my question is does it worth to make a dedicated web API with Authentication and Authorization (coz ASP MVC's Authorization is different from Web API's).
Please advice me, would it be any problem if I kept using my ASP MVC web application as json API for android application ?.
you can use an MVC application, you can have some controllers which return JSON data only and call those from anywhere. You still need to authenticate the access to them when you call them from another app though.
Your other option would be to rework your architecture a little. Create a proper WebApi, sort out the authentication to it.
Once you do that, you can call it from both your MVC and any other app that you have, the same way. This way you keep things consistent and your data comes from one place.
If you call your MVC controllers from another app you are basically putting the pressure on the MVC app which now needs to serve an external app as well. Too many calls will then affect the performance of your MVC app.
It's much easier to scale an API properly instead.
I prefer to add JWT security to my APIs. Then your MVC app becomes a client, the mobile app another client, if you need to add some user information, you can, you can also add extra claims to your tokens if and when needed.
Have a look here :
https://jwt.io/introduction/
https://devblogs.microsoft.com/aspnet/jwt-validation-and-authorization-in-asp-net-core/
I used IdentityServer 3 7 4 with good results in the past: https://github.com/IdentityServer/IdentityServer4
I'm going to create an app for iOS, Android and Windows Phone that will expose the same features that is currently available from our website which is currently being re-developed, and one of the main feature is a search feature. The website along with all the layers are all built with .net (4.5.2) and sql server and we need to expose all the services to be consumed by the mobile apps. The good thing is that it's up to me to decide how they should be exposed, but I'm not sure what's the best technology/protocol to use. What I've been told it should meet is performance/responsiveness. I thought about exposing the services as a WebAPI layer but I'm not sure if it's the best way to achieve such a requirement.
What would you recommend? Does anybody have bone through a situation like this?
Adding an api layer to an existing web application is pretty easy and I think is perfect for your needs. That way you can essentially wrap your existing functionality with the api.
See this link
Since you are redeveloping the server side, I would take a close look at Azure Mobile Services. If that doesn't work for you, and you need something more custom developed, I would still consider Azure hosting with a Web API layer - Web API is definitely the way to go here as it provides easy way to exchange mobile-friendly JSON with a thin layer over your services.
By the way, for any new .NET development, I would go with ASP.NET vNEXT
Since you are targeting multiple clients, you should expose your business as restful services that return data as JSON and also I would recommend using OData (Open Data Protocol) which is an OASIS standard that defines the best practice for building and consuming RESTFul API.
Also OData provide useful querying techniques for example the following URL will return first 2 persons in the system who have registered at least one trip that costs more than 3000, and only display their first name and last name
http://services.odata.org/v4/TripPinServiceRW/People?$top=2&$select=FirstName,LastName&$filter=Trips/any(d:d/Budget gt 3000)
For more information about OData please check http://www.odata.org/
I'm going to build application for web (asp.net mvc) and mobile (iOS and Android). And all three of them must communicate (share data, user authorization etc.) . What is best way to this ? Using asp.net web api or azure mobile services ?
EDIT
I was also wondering what was best practice for scenario like this: I have data base and business logic in one project which needs to communicate whit web and mobile using service. So which technology is best to develop this service Azure or web api or smth. else ?
Your question is very general.
ASP.NET Web API is just a framework to build RESTful web services which you can host everywhere. It does not help you with your task to "communicate (share data, user authorization etc.)".
Azure Mobile Services is an Azure hosted PaaS that actually provides everything you need and even more. It also provides you with ready-to-go RESTful web services that you might implement using ASP.NET Web API as well, but in addition to that it also provides support for federated identities, data sharing etc.
So, I would say since you seem to be somewhat new to this area, you should try Mobile Service, for they are very well documented and there is plenty of nice tutorials suitable for beginners, here is my favorite one.
You can also download a project template for Android and iOS after you have set up your own mobile service and just extend it. This is really a great help for beginners and hobby developers.
UPDATE:
Let's approach your question with some fictional scenarios for different solutions offered by Azure:
Azure Mobile Services cover the scenarios where you have multiple (mobile) devices running occasionally connected applications that need to synchronize their content through the cloud.
AMS provides you with the possibility to implement the custom processing logic for data requests and updates; it hides the burden of implementing and hosting a web service.
About 90% of the logic is set or written directly in the management portal, the rest is just the client logic.
The main purpose of this service is data sync (this is the core functionality), all other services (authentication, logging, scheduler) are just auxiliary.
The language used for development is JavaScript, the whole development is similar to server-side development using frameworks like Node.js.
Azure Web Sites is the way to host your code within IIS, that usually would be a web page, but nothing hinders you on hosting your web services (Web API based or even full-fledged WCF) here as well. Azure Web Sites are easy to deploy and this is a rather cheap solution for hosting web services, provided you allow other IIS applications (from other users) to run here as well (shared instance), but you can also prioritize your application by going for a reserved IIS instance (and pay more). Sure, you can reuse most (virtually all) of your existing business logic here (unless you need something exotic like interop or shell access that can't be hosted in IIS natively). The disadvantage of this solution is that your logic will run within the context of your web service and for long running processing this might be a non-optimal solution.
Azure Cloud Services allow you to defer the processing of logic rules and to decouple the logic from the service input. In this scenario you can have two kinds of roles, typically called web role and worker role. Web role provides endpoints for your services and queues the requests, the worker roles reads the queue and does processing. This allows you to fine tune your load balancing and capacity planning, increasing the number of parallel instances with web roles and worker roles.
I am trying to develop a system that involves a:
server with a database that will handle the system's logic and manipulate data
an android app that will interact with that server (pull and push data into the server)
a website that will do the same as the android app, but from a website with slightly different data.
What I thought of is to use SQLite with Apache Tomcat installed on the server and deploy a Grails war file on it. That will take care of the 'website' side of the system. But what about the android app? Can it communicate with Tomcat as well?
Tomcat will suit your needs. I would look at hosting options though. Are you hosting your own server, or do you have a hosting provider? Do you have experience hosting a tomcat server etc. Do you have experience with java web applications, or other web frameworks? All of the above, and probably more should lead you to your decision on what type of framework/language to use on the server. This in turn will lead you to your options for hosting, and web-container to use.
Once that is determined all major web frameworks will allow you to publish web-services Rest, Soap, etc. that can be consumed by an android application.
Also, if you are planning on providing a web interface and service at the server level, my guess is you are going to be storing a fair amount of data, I would look into a more robust and scalable database such as mysql or postgres. This post contains some insights into this.
If you have an API that is web accessible, an Android can access it.
Android shouldn't have any problems communicating with Tomcat.
Look at http://grails.org/doc/latest/guide/13.%20Web%20Services.html for more information.
A RESTful web service is most likely what you'll need. Android can consume SOAP web services but it requires more work for less overall functionality.
I want to create a very simple rest-like web service to be used by an android application. The web service just needs to offer a way to add user entries to a simple database and retrieve other users' entries.
What would you recommend as a platform to accomplish this?
I was thinking google app engine might be a good way to get this going without worrying about hosting but asp.net mvc or django are other possibilities.
I know this isn't a direct answer but I would shy away from any sort of offical XML-based web services. I've found that JSON is far less verbose and generally leads to faster response times as opposed to full blown SOAP messages. I would urge you to evaluate JSON as your "transport" mechanism.