From a software clients' perspective, a good software service will exhibit the following characteristics:
1. Simple to use. You ask it for stuff and it gives you back precisely what you want. If there are any failures, these are reported. The service should fail fast. No slow insidious failures should be allowed.
2. The chunkiness or chattiness of the API should take into account the useage context. The cost of remote invocation should be factored into the design. In a distributed enviroment it might be worth measuring the cost of providing a chunky API vs a chatty interface.
3. The service should expose an interface for metadata and other out-of-band information.
4. The service should be interoperable - dont tie the service to platform specific return types unless the requirement explicitly states so or there is a compelling performance reason to do so. This assumes that you have measured the benefits of doing so.
From an implementation perspective it is desirable that the service exhibit the following attributes:
1. Statelessness - an invocation of the service at time t + 1 should be independent of the invocation at time t. The services' invocation history is not important. The "now" is more important than what has gone before.
2. Operations should be defined interms of concepts in the domain. Parameters and return values should be defined interms of domain objects. Beware of primitive obsession, i.e passing strings, int, floats etc when you should really be returning well encapsulated objects or passing parameter objects.
No comments:
Post a Comment