When your defining your service contract why create a strongly typed interface as opposed to something very generic?
as opposed to
My team and I are currently at odds to which approach has better value to our clients. I favor the first approach.
The first approach puts a data model on our service which is easy to understand while the second would require some metadata service to describe things like structure. The second approach (they prefer) is easier to consume because it does not take much logic to translate the response.
The other argument for the second selection has been that since the clients of our service know what an income statement is then they don't need structure.
Now I have read books on SOA and I understand the value of putting a model on top of your service but can anyone help me explain this benefit in a more precise way?
The first approach is the "right" one :
- A "true" business contract
- Easier to check with a DTD or a schema
- Means what it means
The second one is only a technical trick, not so easy to "consume" as you have to check it by specific development.
Service Contracts have to be explicit, clearly understood by each part and messages should be strictly checked as soon as possible.
What do you prefer as customer of an API?
Map result = service.getEmployee(1);
String firstName = result.get("FirstName");
String lastName = result.get("LastName");
EmployeeInfo employeeInfo = service.getEmployee(1);
Which choice are easier to read for you?
Which choice are more difficult to make a mistake (e.g. "FitName")?
Those are others reasons.