Page 1 of 1

Designing with or without a services layer

Posted: Wed May 23, 2007 9:04 am
by GeXus
I've seen some companies who actually build their entire application based on a SOAP api. So basically all of the logic is in the API, then they build their own site on top of the API.

I was wondering what you think about this type of development, I could see it being a really smart way if you ultimately will have an API for 3rd parties and would want them to have the same functionality you have, but what if your not planning on having a public API? or what if you might have a public API but only a few functions..

Just would like to know what pros and cons you see in doing this... For Pros, I see the obvious, easily portable. But for cons, I see that it's potentially slower and will require more development.

Posted: Wed May 23, 2007 9:59 am
by kyberfabrikken
It would provide a high degree of decoupling. For example, it would be easy to replace one component with something written in an entirely different programming language. An you'd generally have very well defined interfaces, which is as such a good thing. But it seems like the trade-off in performance and development time would be rather expensive.

Posted: Wed May 23, 2007 2:03 pm
by Christopher
In computing there is a name for "slower but better" -- it's called the future. ;)

I imagine that we will be dealing more and more with "APIs" (as if we aren't already?!?). At some point, as performance improves, it will make sense to move more and more things to a system independent interfaces. Obviously N-Tier designs will help you minimize the changes needed to the application as this happens.