I am looking to get into doing some iOS development for a nice addition to a project i am running.
The main project is currently written in C# and is mainly asp.net with a few windows services.
I would like to incorporate this to be able to develop a basic iPhone app as a proof of concept.
From what i have read and understand, its generally best practice to use JSON as a communication medium for iOS.
I am thinking about using WCF to create the API methods so the iOS app can connect to these services to get the data.
Are there any nice tutorials to do this?
Take a look at:
Developing RESTful iOS Apps with RestKit
I do this all the time. WCF Data Services (OData) are the way to go. With OData services, you can specify that you want JSON response by passing (Accept - Application/JSON) in the HTTP Header and OData will return JSON to you.
I have used several libraries for getting OData (which are REST services) from iOS. Microsoft's iOS OData implementation is pretty lame. RESTKit does a really good job for what it handles, but is really painful if you have to do something that it doesn't. I have also used ASI - it is much more flexible than RESTKit, but is not without problems. I ended up writing my own and it suits me just fine.
For a beginner, I would recommend using ASI over RESTKit. RESTKit, while doing a lot of the heavy lifting for you, takes a bit to get working right.
There are two things that are not standard when receiving JSON responses from OData.
1. All responses are captured in a JSONDictionary with the key of "D".
2. Dates are serialized to the JSON standard (number of seconds since 1970), but they are placed in a string like so: /Date(1212353), so you will have to parse out the Date() part of the string before you can use it.
RESTKit doesn't handle either one of these issues natively, so you will have to deal with them if you choose that route. Personally, I would go the ASI route until you learn enough to write your own.
I am considering open sourcing my solution - if I do, I will update this response with the link to it.
---UPDATE----
Just to be clear - if your server side system uses WCF Data Services, otherwise known as OData, then with minor tweaking, RESTKit plays nice with it. If your services are traditional WCF Services (i.e. SOAP Binding), then you will not be able to get JSON out of them because they are bound to the SOAP protocol (Unless you create a custom Behavior to translate it - which I wouldn't do). It all depends on what your services do in essence. If your services are typically data exposure/manipulation (i.e. addCustomer), then you should expose them as OData. If they are truly operations, then you should maybe consider exposing them as actions from a MVC site. Either of them can get you REST services using your existing infrastructure and platform.
If you're using Objective-C to develop the iPhone app, I'm not sure WCF is the best web service technology to use on the server. Check out ServiceStack to create a RESTful service.
Refer following link:
http://www.kotancode.com/2011/04/26/backing-your-ios-app-with-wcf-json-web-services/
It has included comprehensive code samples as well.
Related
I am responsible for developing the software for a printer-like device, for which I am using C#/.Net and WPF. We now have the necessity for making this software network-capable, so that the device can be remote-controlled over a local network.
The idea I currently have, is to be implement some way of calling the API-functions of our software over the network. This could be done by a client-side DLL, which sends the commands for the API and receives their responses as well as any events, that the device-software issues.
To this date I have only worked a little with socket-based communication using TCP/IP, where I explicitly sent strings over the network and received them on the other side. I did this completely synchronously. However for the new implementation I will need asynchronous calls to the API to query state, issue events, etc. and it seems like it would require considerable effort to implement this using socket-based communication (am I wrong?). I will have to avoid too much custom implementation, since I am under a time-constraint for the implementation.
In my search I came accross the possibility of using SOAP in ASP.Net, which from this CodeProject post, seems to be what I am looking for and does not seem to be too complicate to implement. However in my Visual Studio 2015 installation I am unable to find the project-type they are using there, which is a "ASP.Net Web Service".
My question is now:
Given my choice of technologies (.Net), would this be the most effective way for achieving, what I have in mind? Is it still possible to do this in Visual Studio 2015?
Update:
As always I found one of the questions afterwards: Here is an explanation of how to create an "ASP.Net Web Service" in Visual Studio 2015, which I have tested to work. Leaves the question, of whether this is the best way to go for what I need.
I think that you would have better luck using web api. Calling a REST based api is a lighter load on the network and is generally easier to set up. It is also easier to call from non-Microsoft based clients and usually requires less coding to get started.
Here is a good tutorial on creating a RESTful web api using .Net Core. If you have a PluralSight subscription, they have a number of tutorials on Web Api. If you don't have a subscription, it is well worth the money.
Web Api and WCF are two completely different frameworks. WCF uses SOAP, which is XML based, meaning that the number of bytes needed to send information is much larger than a RESTful service in Web Api. It is much easier to write and deploy a Web Api application and client than it is to write the equivalent in WCF.
Does anyone have experience using ASP.NET MVC project as a Web Service?
i.e. using ASP.NET MVC without Views, so other applications can use the URL to GET or POST to the actions in the Controller.
Has anyone used it? If so, are there any drawbacks for not using Web Service project instead?
Thank you all in advance!
It really depends on the kind of application you're writing. I would actually argue the inverse of LukLed's position - SOAP-based services are better suited for internal clients when you want to support things like Windows Authentication, or different protocols like TCP or MSMQ.
Using a more web-style of GETs and POSTs around specific "resources" starts to get you into the REST architectural style. This technique has a few distinct advantages to me:
The response is usually smaller, particularly when using lightweight formats like JSON
Because of the simplicity of the requests and responses, this makes it much easier to use in mobile / native applications (see Twitter's API, for example)
The service you create can be self-describing and discoverable, because you can link to other parts of your API just like normal web pages.
One article that particularly helped me understand the tradeoffs here is Martin Fowler's "Steps Toward the Glory of REST." That being said, it may or may not be the right fit for your application.
If you do choose to build a more REST-based service, definitely consider using the ASP.NET Web API built into MVC4 as others have mentioned. It's currently in beta, but Microsoft felt good enough about it to give it a go-live license.
UPDATE:
Since ASP.NET core, ASP.NET web API has been integrated into MVC 6 project.
https://wildermuth.com/2016/05/10/Writing-API-Controllers-in-ASP-NET-MVC-6
If you want to use simple GET and POST calls, MVC will be good choice. ASP.NET MVC 4 will have support for creating HTTP based APIs. You can read about it here: http://www.asp.net/web-api
Web Service created in Web Service project can be easier to consume, because it can generate WSDL file, that can be easily read and used in many different languages (by using SOAP protocol). On the other side, WS can create huge XML responses, that could be many times smaller, if you used your own format.
If you want to spread your web service around the world, allowing SOAP will make life easier for many developers. SOAP can be used by people, who almost have no idea about programming. If you'll use it internally, prefer speed and simple requests and responses, you can use MVC.
New ASP.NET MVC includes Web Api Kit, which can do exactly what you want. With current version you can still use it. There are no real drawbacks to it
I'm developing an ASP.NET web site with a n-tier backend utilising nHibernate - all good. As part of the development a large portion of the Interface will be written in Flash or more specifically Flex 4.5. In previous projects I would've created a webservice to broker data and actions between the Flash Interface and the business logic, however I'm looking for a more flexible solution that would allow data / objects to be easily passed to and from the service endpoint without too much redevelopment and with the onus of easy consumptionby Flex and others.
Enter WCF that seems to provide a robust server-side solution where we can use the existing POCOs in the business layer that can be easily serialised across the wire, amongst other things. Unfortunately I'm unsure (and inexperienced in this field) at the best direction to enable the communication from my C# WCF webservice to my Flex application, there certainly seems a few directions but without a clear and concuse path to take.
I would also like the service to be able to communicate to other non-Flash clients so locking myself into one particular route is something I would like to avoid. After some research I believe the best approach is for the WCF service to output lightweight data (i.e. JSON) or POX that should be easily consumed by Flex and other clients. Unfortunately my prototyping has been rather frustrating where the only end to end route I've got working is to Import the Webservice into the application and setting the WCF service to use basicHttpBinding, something I believe I should be avoiding as we need to implement somekind of security and the desire to keep communication as lightweight as possible. In addition, File Uploading would have to be factored in at some stage.
In short, what is the best method to have Flex communicating with WCF (and that's even if WCF is better than say ASMX) given the brief scenario above? In addition, I would really appreciate any tutorials or links that would demostrate an end-to-end system.
Thanks in advance - S
Flex has all problems and I wish flex and flash die soon if adobe is not keep up with today technology. I had a same problem to integrate ArcGIS-flex > WCF > CRM(Oracle). I found a solution with third party. This may help you if you decide to implement your solution using WebOrb
http://cookbooks.adobe.com/post_Connecting_Flex_4_with_WCF_Services-17006.html
http://www.themidnightcoders.com/products/weborb-for-net/developer-den/technical-articles/flex-net-integration.html#c1057
I'm confused about the usefulness of WCF in consuming non-UTF services. I decided to try and give it a go, in lieu of .NET 2 web services, and quickly discovered that out-of-box it cannot consume ISO-8859-1 web services. After googling a bit I learned that you need to create a custom message encoder (i.e. http://msdn.microsoft.com/en-us/library/ms751486.aspx).
Comparably, if I wanted to use .NET 2's web service model, I just add a reference and it works - no need to write a custom encoder. I've decided to use the easier of the two methods, since I can't justify writing and testing a bunch of code I don't need.
I am however curious why anyone would use WCF when they could use the faster 2.0 method. This is a rudimentary question - I'm new to web services, and just using them to pull data from several third party vendors. All I need is the ability to consume the service, throw some credentials, call methods, and get objects back - I'm assuming WCF goes above and beyond that, somehow.
Classic web services are by no means 'faster' to employ than WCF services. WCF has only a small learning curve to get going with stuff we used to do with webservices in the past.
Maybe in very simple scenarios you can accomplish the same thing with an asmx web service as you can with a WCF service using a basic HTTP binding, but among the numerous benefits of the framework (industry wide standards, multiple protocol support), is the fact that alot of the plumbing has already been done for you (in terms of communication, security etc), allowing you to focus on your business logic.
Maybe asmx provides what you need, but the technology is deprecated. If you do a google search, there is tons of websites comparing the two. I would advice to take the oppertunity to start learning WCF!
Hope this helps.
If all you're doing is consuming an existing non-WCF service, then the choice to go with WCF is probably only going to depend on other factors, like if you anticipate consuming WCF services in the future and want to have a uniform codebase.
WCF is an umbrella with a single interface for multiple "bindings" such as HTTP-with-REST-or-SOAP, named pipes, MSMQ, TCP (formerly .Net Remoting), all mixed in with different options for security, authentication, transactions, reliability, etc. So if you were consuming multiple services that were exposed in a variety of ways, then WCF would help you tame them all with a single API.
I searched a lot, apologies if I missed something obvious. And thanks for reading the looong text below.
I have a 3rd party (read: No way to access/change the source) application here. It consists of a server (Windows service) and an API, that talks to the server via remoting.
For several reasons I'd like to expose this API over WCF (see subject: One reason is a WCF client).
The problem is, the API is
unchangeable (follows 3rd party rule)
using no WCF itself (it is serializable/MarshalByRef where necessary for Remoting)
using lots of interfaces and internal implementation classes
Following 1 I cannot use the (quite intrusive) WCF attributes myself.
Following 2 the API itself can be used "over the wire" (they support remoting via TCP and HTTP), but remoting is not good enough for me.
Following 3 I have mostly interfaces (which WCF won't handle well, cannot (de-)serialize). The implementation classes could be sent over, but - I cannot access them.
The general usage for this API is based on a single interface (and its members/properties), so the typical usage is like
var entryPoint = new ApiClientEntryPoint();
entryPoint.SomeMethodCall();
entryPoint.PropertyExposingAnInterface.SomeOtherMethodCall();
and so on.
What I'd really like to do is generate (with as little effort/code as possible) a proxy (not in the typical WCF sense) that I expose via WCF and that serializes this hierarchy mapping every call/property on the client to the real thing on the server.
The closest I've come so far is stumbling upon this project, but I wonder if there are more/other tools available that take a medium to large part of this work off my shoulder.
If there are any general other advices, better approaches to wrap something preexisting and unchangable into WCF, please share.
My advice is to use a facade pattern. Create a new WCF service that is specific to your usage and wrap the 3rd party service. Clients would talk to your service and you would talk to the 3rd party. But clients would not talk to the 3rd party directly.
This would work in most but not all scenarios. I'm not sure of your particular scenario so YMMV.
BTW you can look at WCF RIA Services which is good for exposing services to Silverlight where you can avoid doing a lot of the hand coding of service stuff. But again depending on your particular scenario it might not be the best way to go.
Edit:
It's now clear that the API is too big and/or the usage patterns of the clients are too varied in order to effectively use a facade. The only other thing I can suggest is to look at using a code generation tool. Use reflection (assuming it is a .NET API?) to pull apart the API and then codegen new services using the details you gathered. You could look at the T4 templates built into Visual Studio or you could look at a more "robust" tool such as CodeSmith. But I'm guessing this would be some painful code to write. I'm not aware of an automated solution for this.
Is the API well documented? If so, is the documentation in a parseable format such as XML or well-structured HTML? In that case you might be able to codegen from the documentation as opposed to reflecting through the code. This might be quicker depending on the particulars.
Okay, hair brained scheme #1 on my side:
Use Visual Studio Refactor menu to "extract interface" on 'ApiClientEntryPoint'.
Create a new WCF service which implements the above Interface and get VS to generate the method stubs for you.
'For PropertyExposingAnInterface.SomeOtherMethodCall' You will have to flatten the interfaces as there is no concept of a "nested" service operation.
Your only other option will be to use T4 code gen ,which will probably take longer than the above idea.