Differences

This shows you the differences between two versions of the page.

Link to this comparison view

it:ad:patterns:public_apis_ain_t_ui_apis_strategy [2019/03/24 12:02] (current)
Line 1: Line 1:
 +[[IT/​AD/​Patterns/​Public APIs ain't UI APIs Strategy/]]
 +
 +
 +
 +<callout type="​Navigation"​ class="​small">​
 +* [[../​|(UP)]]
 +{{indexmenu>​.#​2|nsort tsort}}
 +
 +
 +</​callout>​
 +
 +
 +<panel title="​Summary">​
 +
 +Creating a public API -- especially when you've factored in using versioned Messages (see [[IT/​AD/​Patterns/​Version Your Messages Strategy/​]]) -- is hard work.
 +
 +Therefore there'​s a natural inclination to reuse the work for the UI.
 +
 +
 +</​panel>​
 +
 +
 +## Notes ##
 +
 +### Why Not ###
 +
 +Don't do it. Reasons are:
 +
 +* Public APIs are public contracts with external vendors -- they have both be well documented, and then not change without very serious business reasons.
 +* On the other hand, your UI is your business presence, and should constantly be evolving to meet [[IT/#​Customer/​]] needs. ​ If your [[IT/#​SPA/​]] web application needs more data in the json stream, or a brand new method, then it should be able to implemented by the [[IT/#UX/]] team without any dramas -- certainly not having to discuss it with the people in charge o f3rd party (those that use the public APIs) relations management.
 +
 +### Strategies ###
 +In some cases, where the public APIs are satisfactory,​ it's perfectly reasonable to try to have the UX api end points in turn invoke the public API endpoints. ​
 +
 +In [[IT/#​WebAPI/​]] this is very easy to implement -- as long as the UX is using DTOs of the same shape as the public APIs, otherwise some [[IT/#​Mapping/​]] between the two will be required...which is not always fun.
 +