I am trying to get the data of UserProfiles from SharePoint 2010 site using Objective-C within xCode.Now I am using the SOAP service in my project. Is anyone able to point me in the right direction here? Thank you....
You probably mean "iOS" or "Cocoa" instead of Xcode.
If possible, avoid SOAP. It's much easier to access a web service via REST and using JSON as transport format - and in 99.8% of all use cases, a RESTful web service and JSON will fulfill all your requirements up to 100%.
What you need to accomplish your task can be summarized into "networking development", which involves NSURLConnection (and related friend classes), and NSJSONSerialization and a few other system classes depending on your needs.
Unless you stay with a RESTful web service and JSON and moderate requirements, networking may become quickly complex. And it becomes unnecessarily complex when using SOAP. Possibly you may want to utilize a third party library which may help here.
I'm assuming you are already familiar with the basic major principles when programming in Objective-C and for Mac OS X and iOS. So, I would suggest to start with reading examples from the Apple docs involving networking and utilizing NSURLConnection (e.g. MVCNetworking).
Related
The community of developers using odata for their REST implementations seem to be the least of all the REST implementations that I usually come across.
Any reasons?
There is virtually no contract. A service consumer has no idea how to use the service (for example, what are valid Command arguments, encoding expectations, and so on).
The interface errs on the side of being too liberal in what it will accept.
The contract does not provide enough information to consumers on how to use the service. If a consumer must read something other than the service’s signature to understand how to use the service, the factoring of the service should be reviewed.
Consumers are expected to be familiar with the database and table structures prior to consuming the Web service. This results in a tight coupling between service providers and consumers.
Performance will suffer due to dependencies on late binding and encoding/decoding between boundaries within the same service.
Source: https://docs.servicestack.net/why-not-odata
OData is a great standard to expose datasets with good tool support (Excel, Tableau, PowerBI...).
As far as I'm concerned it saved me a lot of time and effort, projecting/sorting/filtering... being available out of the box without having to code anything (especially with .net). It's my go to option for RESTful APIs on table like structures.
I had an interesting conversation with a contractor from one of the major outsourcing companies the other day. He has built restful APIs for many customers and when I asked if he used OData sometimes, he replied 'we don't do OData, we prefer Json' (sigh...).
So I guess one of the possible answers to your question is ignorance, many simply don't know OData or understand it...
ok there is no real way to connect to soap within ios5... sadly enough.
I cant really believe that things that take 3 lines of code in php,
$client = new SoapClient("scramble.wsdl");
print($mirror = $client->sendAndGetString("hello_world"));
need 366 lines of code in objective c? And that on a device that has one of the biggest number of ria's and web apps.
Kind of disappointing -
Are there any new libraries I am not aware of?
If I talk to our web developer team they maybe switch to another service type that is more supported by IOS.
What would be a alternative then?
Thanks
The difference between dynamically typed languages such as PHP and statically typed languages such as Objective-C regarding RPC protocols is that while dynamic languages typically allows you to wrap "any" service in run-time by reflecting out their metadata (e.g. WSDL), statically typed languages normally requires a code generation step before the compilation phase.
Two popular code generators seem to be wsdl2objc and sudz-c. See also this question.
Regarding alternatives, I have good experience using both JSON and XML-RPC, as well as the more schema-oriented Thrift and Protocol Buffers (ObjC).
I've written several tutorials about using SOAP services in iOS with Wsdl2Objc: http://brismith66.blogspot.com/search/label/iPhone%20Development
For me the easiest way is to use good tool to generate all required classes. Personally I use this site:
http://easywsdl.com/
It supports quite complex web services and is very easy to use.
I need to implement basic RESTful functionality in my app e.g. post/get/delete + json parsing.
What would you suggest to use as a framework:
1) Resty http://projects.lukeredpath.co.uk/resty/ (ARC?)
2) http://restkit.org/ (ARC?)
What the advantage of each of them?
The reason I am asking is because yesterday i implemented some RESTful features using ASIHTTPRequest, but today I read is not being supported anymore :(
One more thing, I have heard there is a build in JSON support in iOS5 SDK (GCD Dispatcher or something like that), would it work for iOS4 client? (is it compile time or run-time dependency?), and can it do post/get requests?
Depends on your requirements.
If you just need some RESTful communication with a server then Resty isnt too bad (Though I never used it, it looks straightforward).
Restkit on the other hand is one powerful package because of 1 ultimate feature. Integration with core data. Restkit is able to parse Json responses, make them into objects and save these objects to core data with minimal coding out of the box. This makes it highly useful in case this is the type of functionality you are looking for.
I would encourage you to define the functionality you need and have a look at the frameworks. If it basic stuff, as you say, then one can argue that Restkit may be too powerful.
As for the inbuilt JSON parsing library, well it is way down the list in priority. These framework already includes a Json parser and they work pretty well. I would seriously consider the advantages before I go on to retrofit these packaged frameworks with a JSON parser of choice.
We've got a bunch of data that we'd like to expose to the world hosted on an asp-net.mvc website. I'd like to ensure that we deliver it using technology that is easy for end developers to implement and not tied to any particular platform, rather than using technology that is unpopular/incompatible with developers.
The kind of requests we expect are mainly to retrieve search results (not many parameters), but down the like we'd like to be able to provide catalogue lookups and the like, which may be more complex.
Bearing this in mind, what is the preferred means of doing this?
Windows Communication Foundation can be used to create both SOAP services (great if your consumers are businesses, using Visual Studio/.NET or Java) or REST services (for people on other platforms). Those are the preferred means of exposing public APIs.
If you want maximum exposure, probably best to use the REST approach, since it is easier to consume from "web" languages like JavaScript. Microsoft has extensive resources on putting together a REST API using WCF.
Honestly, for the kinds of requests you say you need to handle, which all seem to be looking up data as opposed to modifying it, the difference is almost trivial - you can switch from SOAP to REST simply by changing a few attributes/configuration options and you could technically even host both at the same time using very little additional code. As long as you stick to WCF and don't use outdated technology like ASMX/WSE then you will be fine.
Reasons to use REST:
Consumable from almost anywhere (including JavaScript, RSS readers, etc.);
It's popular (in use by Google, Twitter, etc.)
Supports many different data formats (JSON, Atom, etc.)
Reasons to use SOAP:
Standardized security protocol (encryption, non-repudiation, etc.)
Distributed transactions
Message Queuing
That's not an exhaustive list but it should give you an idea of who the target markets are for each. If you're hosting a very open, very public site designed to be consumed by anyone and everyone, go with REST. If the service is part of a business system and you need to guarantee reliability, security, and consistency of data, you'll want to go with SOAP. Choose the appropriate technology based on your target market.
Create a RESTful API. As a developer who often consumes web services, it's what I would expect and prefer.
Many popular services (digg/twitter/netflix/google) are moving to REST over SOAP, so you would be wise to follow suit.
If you do create a REST API you should also create a WADL file. It's WISDL for REST. They're not well supported yet, but they're not hard to create and they'll become more useful as support increases.
YOu will want to check out odata. Look at odata.org and live.visitmix.com/videos
This will give you REST access, metadata support like in SOAP, interoperability with the whole office stack and if you are using WCF Data Services you can implement it in a matter of hours, days at most.
Take a look at netflix.com, they have done it right (IMHO).
Is it a good practice to develop web-service and web-site in two different languages, on two different servers? E.g. right now I create a Java web-service running on Glassfish and Ruby on Rails presentation layer running in the same server.
I'd like to leave web-service on the same server but use Ruby 1.9, running in Passenger.
Is it a good idea? I don't have experience in architecture of web-apps.
If you write a contract first web service that consumes and produces XML, you can talk to any client that can make an HTTP GET or POST request in the appropriate format. SOAP or REST, doesn't matter.
I've written Java/Spring web services that started with an XSD. A Yahoo UI RIA client took the WSDL, made an HTTP POST to send the request document, and displayed the XML response in a nice data grid.
Technically, yes you can most certainly do that. That is one of the advantages of using WS. They are interoperable.
However, I would give some consideration to the thought if someone else were to maintain it and has expertise in only one of the two platforms (RoR or Java). It is always best to ask :-)
In terms of the architecture of the system, yes, this is a "good practice". By good, I mean that it achieves the goals, does no harm, and enforces separation of concerns.
I've been developing on an architecture that has a similar structure. The user interface is .NET and uses Java Web Services. That web services then are responsible for all interaction with the persistence media, third party components, etc.
I'd say in any system you should be working to abstract your user interface logic from your business logic. It's just good separation of concerns. Using web services to do that is just one way to achieve that goal. I'd recommend using web services in the case that you will re-use those business services in other use cases in your system.
One more thing; after using two different technologies on the UI and WS for the last 8 years, I've learned that most of the challenges are organizational, not technical. For example, it's harder to find those new developers that have both skills you're looking for to maintain your app. You end up having to find an expert on one and then train them on the other technology.
It depends on how similar they are.
If your web service basically mirrors your website in functionality - then it makes a lot of sense to reuse existing code and thus to make them the same thing on the same server.
Note - this is not the same thing as entangling tiers as your views are still separate from your business logic.
From the Ruby-on-Rails perspective, the "web service" and "web-site" are often interchangeable as they are exactly the same code, with only the view-template differing (html for the website, xml for the web service).
If you build with a RESTful architecture in mind from the beginning, then you can achieve this with the minimum of duplication and with all application layers correctly decoupled.