Comment by tracker1 | Hacker News Reader

Comment by tracker1 | Hacker News Reader

Parent Full thread

I'll go a step farther... the consuming API client should be in a different language/idiom than the server-side implementation (assuming multiple languages are going to be used in your environment).

Too often I try to access Java or PHP web services from .Net, where the tooling is very strict, and it just falls apart. Or I'll have to use something via JS that is just excessively painful to use in practice for no good reason.

I've also seen time and again layers of indirection or other design patterns used without any consideration of why they are being used in that instance. You don't have to hide your data tier behind factories of repositories. You don't have to make everything an interface. If you aren't going to test anyway, make the code as simple as possible. I tend to favor only adding complexity if it makes those complicated pieces easier to use in practice, and even then not all the time.

Sorry for the rant, I just see time and again certain levels of complexity without flexibility or consideration for why.

> Too often I try to access Java or PHP web services from .Net, where the tooling is very strict, and it just falls apart. Or I'll have to use something via JS that is just excessively painful to use in practice for no good reason.

On the other hand trying to use anything from .NET land that implements WS-Security from PHP or Java is also exceedingly painful. I recently had to integrate very similar APIs from 5 different companies into an internal application...

One used an HTTP(s) REST API written in PHP, it used mod_auth and I was done in 30 minutes.

One used SOAP with some custom extensions, I hacked around a bit with the PHP SOAP classes and was done in a few hours.

One used WS-Security, and after a few days of hacking around I ended up using Netbeans' tooling to generate a Java client that could consume the service and forward the results to PHP.

Another used a (more recent) version of WS-Security and the same trick wouldn't work, so I contacted their support who admirably tried to create a java client to consume the service, gave up, and created a regular SOAP bridge for us to use.

One company is still trying to get our AD credentials set up with their vendor software that uses Biztalk somehow (they've been scarce on the details) after two months of waiting.

RESTful services in PHP and Java may not have a pretty GUI configuration tool, but they are much simpler to get working than SOAP and any of the MS extensions in my experience.

It's worth noting that you can mount very simple SOAP services in .Net (doesn't mean that people do)... WCF for example gives a lot of ways to mount your services together, or separately.

That said, I've never really been a fan of SOAP in general, and WS-(death)* is painful in any system. Funny enough, I've found node.js to be the easiest middle-man to coerce into using different services as a gateway, and it's my go-to when a wsdl doesn't import cleanly into a .Net project, and just define my own JSON/REST interface in front of the foreign services for the parts I need.

AD integration is particularly painful, and pretty much only works in IIS, in that case, I'd lean towards writing a shim in ASP.Net MVC exposing JSON endpoints, in a similar fashion.

Reply on news.ycombinator.com