I have been provided with a WebService with a REST Interface, implemented as a DLL.The documentation is really poor, and does not detail all the possible parameters.
Is there any way to get all the parameters that the DLL can accept without disassembling the DLL(something like a man function)?
Thanks a lot for your help!
In general you can't.
Of course you can list all functions with DLL Export Viewer and hope that you will find something like man function. But most probably you should use trial and error method here. Call functions and examine what they do.
PS: if there's a way to obtain documentation or source code, it will be the most correct way.
The short answer is "very unlikely". It really depends on how those services were implemented. If they really are REST, they should comply with the HATEOAS principle, so you should theoretically be able to navigate all the services just by following links provided by the responses. If this is true, all you need to know is the entry point of the services.
Or, there could be a WADL describing the service 'topology' (https://en.wikipedia.org/wiki/Web_Application_Description_Language).
On the other hand, if the services were not implemented this way (I won't say 'properly', but..), I am afraid you don't have many options apart from diving into the implementation.
Related
I know that there are many API's like json,Facebook,twitter etc for developing related applications on iphone....but how to understand an API?This might be scilly question but I want to know how? what would you suggest for for a beginner?
You should find relevant documentation and read through some code examples utilizing the API.
If you are looking for information about the iphone, as the tag suggests, then read through the information here. There is an entire section dedicated to sample code. If you really can't understand how to make something work after some effort and some googling, then you can always ask on StackOverflow.
When ever I came through adding new API in my project I usually scan though documentation to find relevant topic to my project then after looking at the some sample code I usually start experimenting with the code to get the desired results and thats it because API is for short term use, you should not waste your precious time on just one API. So steps are, 1) find the relevant topic then 2) read sample code and 3) write your own code to get the desired results. 4) through away that API.
Cheers
Ayaz Alavi
If it's open source, read the code from beginning to end. Or to see why things were designed in a certain way, maybe try reimplementing parts of the API.
I do realize this is a duplicate question, however the only other question is quite old, so I would like to know if anyone has had any recent experience with the latest version of wsdl2objc.
I am doing an application that will communicate with SOAP Web services exposed by a third party application (it only exposes them this way unfortunately). As far as I understand all wsdl2objc does is convert the WSDL to something useful in objective C code. I have also done the tutorial icodeblog intro to soap
So has anyone used the latest version of wsdl2objc?, what is your experience with it?, did you run into any problems with it?. Please let me know. Also some code sample would be really great.
Any information available on using SOAP Web Services with iPhone would be appreciated. Thank you.
-Oscar
My most recent experiences with wsdl2objc is that it's on the right road, but not really there yet. It's definitely the kind of program you'd want. It just may or may not be able to handle the WSDLs you actually have.
Short answer: try it and see if it works for your WSDLs. If it does, hooray. If it doesn't, you have two options. For reasonably simple WSDLs, write the SOAP by hand. This often is actually the easiest approach. If the WSDL is complex, then use gSOAP to get to C++ and then wrap the C++ in Objective-C++ (or use the -c option to gSOAP and wrap the resulting C, whichever you're more comfortable with).
I think this gives a good example of how to configure your environment (for noobs like me)
http://blog.futurebytez.com/2010/05/calling-web-services-using-wsdl2objc.html
The official wiki for wsdl2objc (linked in the article) has a code snippet which gives you the basics.
I've been trying to find a good form of RPC to standardize on, but so far I've ran into a ton of walls and was wondering what the stackoverflow communities view was.
My ideal RPC would provide the following:
Somewhat wide support in other languages, in that people shouldn't have to write a custom stack to use our server
Input validation
Ideally, some way to turn the above input validation into some sort of automated documentation to distribute
Clean and maintainable code
I am a fan of the catalyst framework and would prefer to stick to it, but if there is a clearly better alternative for RPC servers I'd be open to that as well.
So far I have looked at the following:
Catalyst::Controller::SOAP
Doesn't appear to support returning of complex data structures, only string('literals'). I could probably serialize data on top of that, but that seems very hacky. It also lets you return a pre-formed XML object, but I couldn't get that to work and it looks like you'd need to re-create a lot of SOAP data structure for it to work.
I do like the idea of WSDLs, but the complexity of the overall spec also makes me wonder how well support for communicating with other languages will be.
Custom POSTing XML based controller
We tried to roll our own by hand in a similar way to how we've seen two other projects do it recently where there is a dispatch url that you post XML to. This lets you have XSD validation/documentation, but required creating a lot more code than we want to maintain at this point.
Catalyst::Plugin::Server::XMLRPC
Gave a warning about using a deprecated method that will be removed in a future version of Catalyst.
No input validation or doc creation, but otherwise the best I've found
JSONRPC
Looks pretty similar to XMLRPC only the module is actually updated. I'll probably go with this next unless someone suggests something better
There also appears to be two different modules for catalyst that do JSONRPC
I realize that REST isn't pure RPC (only a subset), but...
I would recommend the Catalyst::Controller::REST and Catalyst::Action::REST modules. They're frequently updated and the documentation is fairly good. There is also a good (but rather dated) example of using Catalyst::Controller::Rest in the 2006 Catalyst Advent calendar titled Day 9 - Web Services with Catalyst::Action::REST.
FWIW, Catalyst::Controller::SOAP does support returning complex data. Take a look at the documentation http://search.cpan.org/~druoso/Catalyst-Controller-SOAP-1.23/lib/Catalyst/Controller/SOAP.pm, which will show you that you can use a WSDL to describe your service. Also, see http://daniel.ruoso.com/categoria/perl/soap-today.html.en for a more detailed step-by-step process.
These I come across this term a lot "crosscutting requirements/concerns" in programming world.
Although I think I have an idea what it means still I do not have a clear idea. I hear it a lot in web service and SOA in general.
Can this be explained using a hello world example?
It tends to mean "stuff that you want to do in lots of places, which doesn't have an awful lot to do with the real meat of that piece of code".
Common examples are:
Transaction handling
Security
Logging
Error handling
I find it's usually mentioned in respect to Aspect-Oriented Programming (AOP) which usually attempts to handle things like this declaratively, e.g. with attributes/annotations. As a gross simplification, it's a case of applying boiler-plate code (e.g. to verify the identity/authority of the user in the current context, or to log entry/exit of the method) automatically without making the code itself messy.
The standard "hello world" example for crosscutting is logging: You have an error in your production system and you have no clue what is going on. To solve it, you really need to see which functions in your code are called and what parameters they get and what they return.
This is a simple task that can be fully automated: Locate all functions (or a subset using a filter of some kind) and add a logging call to them which prints the name and the parameters. Since the code contains all the information you need to complete this task, what you really want is a tool that does it for you and which does it in a single place (instead of having you edit thousands of source files adding log statements everywhere).
I recommend you look at a framework like Postsharp and try out this example from the postsharp site. If you know java a lok into AspectJ is worth a look. But first you may want to read the link posted by Jon Skeet :)
I know that Flickr provides both XML-RPC and REST ways of working with it.
There are standard XML-RPC libraries for every language (For example, Python has a built-in one xmlrpclib).
Standard XML-RPC libraries takes care of the serializing/deserializing as well as sending/receiving the responses.
It seems to me that websites that use the REST style for the same API would end up writing their own libraries in each language. Example: the Yahoo! Search SDK.
To me, it seems that the XML-RPC way is better, but all the evidence is to the contrary. Why?
So:
Why are most web services in REST style, and not in XML-RPC?
Are there downsides to XML-RPC that is not apparent?
Rest is not just easier, its a lot easier.
Xml-Rpc/soap has a lot of moving parts and a hefty amount of overhead, cognitive
and otherwise which (very often) is not needed, its complex and unless you
specifically need some of the features it provides it's just not worth it
Not every service request needs to be packaged up as a formal function call with
parameters
REST is also a formal system that's well defined and a great model for representing
the resources available on the web (hence the term REST)
Having said that, it's easy to make a lot of newbie mistakes using REST so google around for how to use it first, you'll be happy you did.
This is a great question. Unless you are taking advantage of hypermedia for discovery and standard media formats then you are not likely to be getting the benefits of REST. You might as well stick with XML-RPC.
Simple Answer: REST tends to be easier to implement
there are many discussions on that on the web, so I won't go deep on the answer. In short: It's easy. Easy to write, easy to understand, easy to debug. You can write it on your browser and it will probably bring back something useful. Very good.
This easiness come at the price of less "possibilities" but the theory goes that in the long run, easiness might be more worthy.
REST is the native architectural style of the Web. (In fact, it was reverse-engineered from the way the Web already works.) XML-RPC and SOAP attempt to take a very different (procedural, imperative) programming model and adapt it to the web. The result is that REST ends up being cleaner and more flexible.