Database Reference
In-Depth Information
many combinations as you want, but please do not forget to put it with utmost diligence
into the repository from the previous chapter and make it public; otherwise, discoverabil-
ity and interpretability of your service will be just a little less than nothing. And that's the
common rule for all the RESTful services, as they do not present formally discoverable
contracts and require the resource hierarchy with clear meaning of operations.
Tip
Just in case if someone got an idea—the first and foremost thing to remember is that we
do not want to start pointless discussions such as SOAP versus REST. We never particip-
ate in such discussion and we use them proportionally in all technical infrastructures
where necessary. We are just pointing out that REST simplicity has a price and some de-
clarations such as "SOAP is dead, all migrate to REST!" are over-exuberant at least.
We truly admire the knowledge, style, and presentation skills of Craig Larman (
ht-
tp://www.craiglarman.com/wiki/index.php?title=Main_Page
)
, one of the most influential
Agile Experts and his ways of making jokes. Although he claims that his jokes lack hu-
mor, we think his jokes are brilliant. Instead, we can try one bad joke here and we hope
that you do not read this topic to your kids before sleep. When a beautiful young Princess
was born, the evil witch predicted that the Princess would die of pricking her finger on her
15th birthday. So, to save his daughter's life, the good King ordered to cut off all the Prin-
cess' fingers.
Simplicity of the REST services came from the visualization of linking resources in an In-
ternet style, based on a unified protocol with a unified (and highly limited) set of com-
mands. Cutting lots of SOAP functionalities initially gave the REST concept a consider-
able boost. Now, when REST services are facing similar challenges as SOAP, simplicity is
not that obvious. Actually, the same thing we can say about OAuth 2.0 (half-dead, half-
alive), and even about SOAP itself. Look, it's not simple, it's not exactly about the object,
it's not only about the access, and it's not truly the protocol.
And speaking about the mapping of basic HTTP methods a in REST services to business
procedures, we should mention that situation when
DELETE
in fact could mean
CREATE
in business terms is very common and that can be quite confusing.
So, where will we put all this bridging? That would be the same approach as in the previ-
ous point. Plan for facade from the very beginning. Implement two mappers for the same
component: one for REST service implementation and another for Web Services. Obvi-
ously, in most IDEs, all it takes is a right-click, but be careful with the code-first ap-
proach. Luckily, contract first is also supported.
Search WWH ::
Custom Search