A programmer should not expose resources within a REST initiative in a “bottom-up” ad hoc manner. Bottom-up development is inherently driven by immediate project needs. For example, how you solve a specific problem with a specific implementation (often driven by the influence of existing applications and associated behaviors masquerading as true business requirements).
What happens when an organization defines and implements REST with the mindset described? The REST implementation simply becomes layered with more spaghetti code of a different form that does not improve business process flexibility. Consequently, a monolithic application in a different technology is implemented often with disappointing results.
To achieve success, a programmer should not define REST in a “top-down” manner. Top-down business process analysis can lead to either “analysis paralysis” – continual refinement of a model hoping to reach perfection (which never comes), or “Big-Bang” projects – trying to define and implement everything at once. Either approach usually creates disastrous consequences (a combination of “death march” projects, and cost, and schedule overruns).
What do organizations need to make progress? A coarse-grained business model driven by key business processes. Not all key business processes may apply but definitely a representative set of high-priority processes to start. Architects and business analysts should collaborate to build an applicable model by extracting key business processes to define a normalized set of functions. Next, group functions together based on behavioral affinity as a straw-man set of initial, target resource definitions.
Resultantly, we have a useful framework for the “real work” – detailed analysis, design, and REST implementation needed for our current set of prioritized projects. Based on business process (and project) prioritization, we identify the needed resources from our business reference model and formalize the definition for the prioritized resources. Ideally, each resource should be driven by requirements extracted from at least two separate processes. Designing a REST resource based on a single use case may result in a fragile, and narrowly defined implementation lacking the flexibility necessary to meet the next set of prioritized projects. Formalization efforts are likely to result in modifications to business architecture – which is fine! We can iteratively enhance the architecture as progress is made towards a successful REST implementation.