I want to use a WCF service and consume it using all the mobile platforms iPhone, android, Blackbery, Nokia etc'
Whats my best strategy for using those clients with a WCF service. it will have to be secured of course.
Thanks
amit
I disagree with SOAP and JSON. Use RESTfull service with POX (plain old xml). It will be most probably supported by all platform. Mobile phones can have limited SOAP stack implementations and JSON is usually used with browsers. My friend has BlackBerry and he continuously complains about its support for JavaScript.
To secure your service use HTTPS.
Use a SOAP or JSON endpoint. Most platforms will have support for these (or it'll be easy to find libraries). JSON is more web oriented (Javascript) but will work in other situations as well.
Mono supports WCF so maybe their iPhone and Android will support it as well.
Totally agree with #Ladislav on not expecting clients to be able to consume SOAP. Seems like SOAP stacks are lacking unless your client is native .NET or Java. Your clients will thank you by allowing them to choose JSON (web clients) or XML (system integration). Secure via HTTPS and basic auth or an API key.
If you already have an existing infrastructure of WCF services that you want to aggregate, or adapt, for downlevel clients you could put that POX (or 'REST') service in front of them and let it handle mapping protocols and formats for you. e.g. HTTP/S to TCP/IP and XML or JSON to SOAP.
The upside is that you will make it easier for downlevel clients to consume your services. The downside is that you've added an extra layer, which will cause complexity. Some tools, like WCF Routing Service (free) or Apigee (commercial), coupled with a solid automated deployment proces can help mitigate this complexity.
To build a REST service that supports XML or JSON, create your service with this template, it's designed for .NET 4.0. From there you can configure endpoints that respond in XML or JSON and let your client tell the service what response type it wants.
EDIT You can also have the service respond in a default format to reduce every client having to specify what format.
<standardEndpoints>
<webHttpEndpoint>
<standardEndpoint name="" defaultOutgoingResponseFormat="Json"/>
</webHttpEndpoint>
</standardEndpoints>
Related
I'm new to the concept of REST. And so far I've used a REST client (Advanced REST client) to make all the requests. But I don't understand the point of it all if I have to use a REST client to access the web service. I mean how then is a layman supposed to access a web service in his browser? And can browsers at all access access web services? If yes then why do I need a REST client?
The layman access a REST service all the time, when they access a web site (though many web sites violate REST principles to varying degrees). The REST architectural style was arrived at by examining why HTTP worked well, and was then used the conclusions to influence how HTTP 1.1 improved on 1.0.
They aren't expected to access a REST web-service, because a web-service is a service which uses the properties used by websites to provide machine-readable rather than human-readable data. A RESTful web-service tries to do this by taking advantages of how HTTP works and working with that. (The earliest "web services" seemingly started with the assumption that the web was a failure and needed to be coerced into working with the sort of RPC model that had been used previously, despite the fact that if this was true there'd be no advantage in using the web rather than the existing RPC protocols).
The layman therefore would more likely use an application that in turn used web services (whether that application was a web application, desktop, mobile, or whatever). The layman uses them the same way that they use any programming techniques; they use something devs built using them.
And can browsers at all access access web services?
Often they can get at least read-only access and sometimes a bit more. When this is the case it can be extremely useful for debugging.
So right now our company has custom SOAP web services that hold functions to do things (e.g. sending emails, getting employee info, etc.) and are connected via Service References.
We want to make the switch to Web API 2, but I'm kind of lost on how we can (or if it's possible) to do that since all of our services interact with SOAP.
I wanted to create brand new Web APIs for each service we have which would hold the methods, but I'm not sure where to start. I've scoured the internet, but I haven't really found anything that answers my question.
Can someone shed some light on this for me? Thanks
well, you can create the Web API Service, and exposes the functions that you need, maybe, this service can be accessed from anywhere, but, the real functionality is on the soap (that can be in a DMZ for example), so, create a class library that consume those services and Web API now use this class library, so Web API will be only a facade.
But, first think, is really necessary have this facade in web api to consume those services?
Remember that if your soap services are built with WCF, WCF has support for HTTP protocol.
What is the most appropriate protocol (SOAP or REST with JSON format) to use with a mobile OS Android or iOS application that uses a web services exposed by a Java/Java EE application?
Which one is going to be more performant and providing security, atomic transaction and reliability?
You'll need to define your security requirements a little better.
SOAP with WS-Security can be used to ensure the integrity of message, and that only the appropriate process can use the data.
It this is what you mean by security, you're better of with SOAP as it has handling capabilities for this.
REST is built ontop of standard HTTP operations: GET,PUT,DELETE,POST, and as such, security is based on two areas:
End to End security, provided by SSL (HTTP)
Authentication, which range from basic HTTP authentication, to custom providers, such as OAUTH2.
From a development perspective, REST based APIs, using JSON dataformat are easier to work with.
My vote goes with REST with JSON.
I'm looking to develop a blackberry application to consume a RESTful service. At the moment we plan to develop a REST layer which we will use to perform searches on a back end database and return the results as JSON.
I have used the Jersey framework ( http://jersey.java.net/ ) for consuming (and developing) REST layers in the past.
This is the first time we plan to develop such an app for a blackberry. From looking around I'm not sure if jersey is supported on the blackberry for consuming RESTful services.
So I'm wondering could someone offer some advice (on jersey or any other purpose built JARs) for using RESTful services on Blackberry? Otherwise we will have to build from scratch the code for consuming the RESTFul service. Or even use SOAP which I prefer not to have to do if possible.
Thanks,
John
Take a look at the JSON.org website, they have lib in Java to parse JSON data(I'v manage to make it work for BlackBerry without to much modifications.
The only thing left to do is a connection to the web service by passing the parameter you need to it. And then parse the response with the JSON lib to rebuild your data model in your native client.
And please don't use SOAP for mobile application.
Please read RIM doc for socket
You can use a httpConnection too
I'm thinking about creating an application for the iPhone and Android that will need to access a common backend to retrieve account information. Can both access a web service over https? What other way would allow me to have one interface to the backend that is accessible by both?
They both work over http and https which is a common enough protocol. I would suggest you go with a RESTful web service so you expose your service via URI's like http://www.myservice.com/weather/zip/98007 which would return an XML blob that can be parsed by the client.
if you are starting from nothing, i'd definitely go with RESTful service that returns/accepts JSON... there are plenty of libraries for both platforms that will accept JSON and turn it into arrays and dictionaries.
I'd recommend using a RESTful web service backend, which is all standard HTTP and/or HTTPS. If you can use Ruby on Rails, its default scaffolding will get you about 99% of the way there and for the iPhone there is an open source project called ObjectiveResource that will automate your communication with this Rails backend. I haven't investigated yet what options are available on Android but since it is all simple HTTP it should be straightforward. I am not the maintainer of ObjectiveResource but I have contributed some code. You can check it out here:
http://iphoneonrails.com
One good approach I have seen used with other services is to write the backend in such a way that it can feed data back in different types - for Android an XML response is best, but for the iPhone sending back plist data is preferred (though it can also work with XML if required). In both cases it's easier to simply POST updates back to the server than to wrap an update in XML.
Both platforms should be able to use whatever form of authentication you wish to use, the iPhone I know supports all methods of HTTP authentication.