Database Reference
In-Depth Information
should be accessible through a unified entry point, suitable for all types of assets/
channels (YouTube, HBO, live programs, and so on). Naturally, all services hand-
ling these sources have different messaging protocols such as REST, SOAP, and
proprietary.
• Inside the telecom organization, we also have services with different messaging
protocols due to their technical nature. Services related to the STBs operations
(the small black box under your TV) are RESTful in general, but some of them
are also parts of Billing and Order Fulfillment, which are traditionally SOAP-
based. The telecom business domain is not exceptional; you can see it every-
where.
With the modern "
Any
content on
Any
device,
Anywhere
" paradigm, telecom providers
should ensure a seamless experience on TV and tablet/mobile devices or any device for
the same content. Thus, our APIs must be universal enough to handle content on managed
and unmanaged devices, supporting REST and SOAP simultaneously (some call it Triple
A, but it fact, we have a fourth A:
Anytime
).
Arguably one of the most complex APIs in telecom for all types of media resources is a
consolidated search. Your client could watch
The Bourne Identity
on his tablet and at
some moment decide to figure out how many Austin Minis were destroyed while shooting
a single chase scene on the stairways in Paris or who else in the history of a spy's paper-
back lost his memory and got conscience convulsions instead. You must instantly provide
him with options to purchase the subscription to Top Gear where Jeremy Clarkson will
teach your client how to drive a Morris Marina or purchase the
The Spy Who Came In
From the Cold
movie from HBO Go (or an audio topic from Amazon instead, depending
on your business affiliations). What could be easier, some say. Those of us who hit some
REST limitations wouldn't be so eager though. How many query parameters can we put in
a browser's search string? What is the maximum length of the query string? How can we
parse the complex query string with plural parameter combinations? Indeed, some of these
questions can be solved by the Google YouTube Search API, for instance, but it would be
much better and easier to use classic SOAP/XML to construct the query XML object. You
will not have limitations on the query string, at least.
Generally speaking, the mapping of standard HTTP methods (
POST
,
GET
, and so on) to
meaningful business operations was never easy and can be done more or less directly only
for Entity Services (Recourses in that matter), where
PUT->add
,
DELETE->del
,
GET-
>get
, and so on. For more complex cases, you will have to do some sort of "triangula-
tion", where the meaning of your operation will depend on the combination of three
things—the resource instance, data type, and basic operation. Yes, you could have as
Search WWH ::
Custom Search