Do you return well
Build Lots of Small Services
Move Quickly. Move Independently.
APIs are powerful in this model
API can feed a UI (Angular, React/Flux)
API can feed Data Services
No Monolithic Dev Cycle Necessary
Build Lots of Small Services.
Make Them Easy To Work With.
Build fast, Build Often.
Choose a Service Model That's Easy To Interact With
This means develop new parts of as a producer
This also means use it as a consumer
The Two Crucial Parts
Data Layer (JSON? Thrift? Protobuf? Smoke Signals?)
REST + JSON Seem To Be Winners (On Popularity, At Least)
Continuous Integration Matters.
The caveat: You need lots of (good) tests.
Consider property based testing (e.g. ScalaCheck, QuickCheck)
Checkins Should Trigger CI Builds
Only CI Should Have Commit Permissions to "master"
These rules will help lead to Continuous Deployment
I adore the Netflix deployment model
Successful CI Builds Trigger "Baking" Of a Cloud Image
New Image is Automatically Promoted to Staging
Deployed Servers are Tagged with CI Build #
One Click to Promote Staging to Prod
One Click to Roll Back to Prior Version
An API that isn't documented is no API at all
[ credit: akka.io ]
Netflix' Hysterix Framework Uses Circuit Breaker & Other Tools to Help Combine Microservices
Meaningless Errors & Exceptions lead to long days (and nights!) slaving over error logs
Nothing sucks quite so much as spending long hours digging through error logs...
... Only to find out it was something stupid that could have been provided in an error message
If you can validate an entire request object, do so.
Return every error you find immediately, and clearly.
If you can pass multiple errors up your stack and return them, do so...
JSON supports Arrays, after all
Provide useful data, not just a generic 500 Internal Server Error
If you have an exception, extract some useful message from it
REMINDER: Exceptions shouldn't be used for flow control
PHP Provides a particularly useful error message...
Parse error: syntax
W. T. F. ?
Nekudotayim' ( פעמיים נקודתיים ) is apparently
Hebrew for "Double Colon"
The main authors of PHP 3+
are Israeli, and probably
thought this was funny.
Imagine how many hapless
devs have misplaced a '::'
and spent hours scratching
Most API platforms have
some sort of Status Code
For REST, Pick & Document
Even if you make up your
own silly HTTP codes, make
sure you document them so
people know what they mean.
There's a proposed HTTP
Error Code "759 -
I also like "763 - Under-
Your API Framework of
choice should provide good
tools for testing it
If it doesn't, consider finding something better
Good testing contributes greatly to feeling comfortable that
what you've built works as
Service Level Tests (HTTP
Helper Level Tests (backend
objects sans HTTP)