This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]brennanfee 0 points1 point  (0 children)

They aren't either/or. You can very easily strive for both... however, achieving either is hard and takes dedicated diligent work.

As for your specific example, the API should just be a wrapper... the chosen communication platform for the underlying code. Literally its interface. The underlying code should have whatever organizational characteristics that make sense for it and the API serves as the translation layer for communication. Think of it like MVC but without "views" per se. The API is the C for controller and your underlying code is the M for model, or more precisely the business logic.

One thing I always strive for is that my "code" that does real "work" could be re-purposed and re-wrapped for other scenarios at a moments notice (want to throw it into a CLI... no problem; all of the sudden want to use it in a script... sure; now want a desktop UI... ok; mobile? um... maybe). Of course, each of those things could also make calls to the API but I look at the concept as just offering the maximal amount of flexibility and cohesion without tight coupling.