Developers -- What do you use for APIs?
 

Obviously it depends on the project, but in general, what methodology do you prefer for developing APIs? Just simple HTTP POST / GET, XML, SOAP, REST, or? And in what format do you return the results? Raw text, name/value pairs, XML, JSON, serialized array?

I used to just pass XML request back and forth, and thought that was great. Then this young, ambitious, intelligent russian who now works for Microsoft convinced me to use SOAP for a large project we were doing together. Absolutely hated it at first, and couldn't think of a more complex way to send data between servers. Once you get the WSDL and everything in place though, it's actually great, as you don't even have to worry about the data transfer part. It's all just functions, plus it can easily be used across multiple platforms (PHP, Java, .NET, etc.).

On to REST right now, with returning either JSON or serialized arrays, depending what they want. Gotta say, I think I found a winner! :thumbsup Clean, easy to develop, flexible, light-weight, and easy to learn. Perfect!

How about you other developers? What do you use for APIs, and why?

Compiled C++ API's?

To interpreter languages a simple query string.

Sometimes, I think programmers/coders get paid by the line — they create overcomplexity.

TMTOWTDI

:Oh crap

We are using both SOAP, HTTP POST / GET, SMPP and some XML feeds.

I like HTTP as then I'm able to see exactly what's going on too :1orglaugh:1orglaugh

SOAP appears to be very stable

mixture of all of them, depends on the api im using

SOAP is great in ways, but a pain in the ass to setup. If you've ever opened up Notepad, and wrote a WSDL file from scratch, you'll know what I mean. Has its benefits though. Once setup, you don't even know data is being passed between servers, and it's the same as calling any function within the software. Great concept, but unfortunately developed by Microsoft, so of course it's overly complex for no reason whatsoever.

Nonetheless, for larger APIs, I think I'm going withe REST from now on. Much nicer, and better to work with. :thumbsup

Let me take a wild guess. You're 40+ years old, correct?

My playing with soap was terrible.

Very difficult to use. Maybe i'll try it again in the future.

SOAP is great, but has its limitations, and it a pain to setup. I think I'll stray away from it from now on. The great part is, once setup, and say you're using PHP, it's the same as including any library. Only difference is, instead of:

You use:

That's it though. Then you just call functions as you normally would. $client->some_func($vars); type of thing, and you don't have to worry about the data getting sent to the other server. It all happens behind the scenes.

Still overly complex though, and a pain though. :( I'll stay away from it, me thinks.

Yep — that means?

Ever since I started in this field, back when I was 19, I've always pinned a developer's shelf life at 35 years old. After that, the creativity and innovation disappears, plus they can't competently keep their mind wrapped around 2000 different things at once, which is what's required in a good developer. I've always told my clients to stay away from hiring developers 35+ years old, as they're not going to be providing you with the most innovative, creative, and cutting-edge solutions, which is what's required to succeed as a business.

That means I have about another 5.5 years to get myself in a management position, where I never have to type a single line of code again.

Not sure if that is a rule, but there are certainly notable exceptions... some of the best developers (= including writing code) i worked with, were 50+.

I remember one guy that was offered countless times to take a management position. He did not want to: he just had more fun writing code. He may not have been the fastest in jotting down lines, but what he did was clean and *worked*. He had a singular gift for writing almost bugless code. We could have released his stuff with no beta testing.

I am a Web Developer. I suppose that is like an Executive Producer in the motion picture industry (similar in function.)

Just for the record, SOAP is not exactly new ... I suppose the "how" part depends on what is needed to be achieved.

If you define a "developer" as someone who develops necessary programmatic code ? I am the guy that specifies the necessary end result.

Seeing how what you do fits into the greater picture is what really counts.

@alf6300: There are exceptions to every rule. :)

http://www.programmableweb.com/apis

this is a nice link

We do the most in XML, we have for the eritoc partys and swingerclubs a XML feed to all pages, clubs, event companys, provider... most of them in plain PHP script.

the ticked system (book a place on a party, show, event...) is a mix of SOAP, php and shell sripting. we have a server only for the event reservation. on the webserver at the client side we run php script that puts a XML file on the drive without any database and crap, easy to run it on the remote server (club owner, event...).
a shell sript checks every hour with a http request (wget/curl) the XML pages on the remote system, put them on a tmp folder and make a short check with a awk script, after them a php script put the informations into the database.

steady customer have a direct access to the XML interface the send a POST request to the server like:
<event>freefuck 2011</>
<do>reservation</>
<person>female:1 male:3</>
with a easy fsockopen and fput php scriot.

i dont like to code 200 include files and 500 php classes for a easy operation :-)

here in germany we have ppl they are "HTML software architect" the need at least 2 inluce files and 5 classes for a "hello world" php script.

Very funny is to see a php script that starts with:
its PHP baby ;)

SOAP is a pain with PHP when you want to add authentication to it "by yourself", ie. without using any other library.

For the REST part, I do like JSONP for its protection against XSS (no direct eval of JSON code here).

You can't be serious. I lose more money with young developers trying to sell me on the latest and greatest rather than giving me what I need. There is something called "cost effective" and that seems to go over the head of young developers. When you hit 35+ you will probably be a much better developer. Hang in there, it will only get better for you.

I prefer to keep things simple:

HTTP POST / GET.

Right, perl rocks, and its easy like PHP.

and a lot more powerful!

The only fallacy with that is the people who developed things such as Google, Facebook, PHP, and Perl were all under 30. There's a reason for that.

EDIT: Sorry, Larry Wall developed Perl when he was 33, so I'm a little off with the under 30 remark.

Right, as we age we understand our errors :)

Soap and xml sucks, way to much data for comm.