Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

API design presentation_1.0

No description
by

Anusha Polavarapu

on 27 June 2014

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of API design presentation_1.0

Marriott
Architecture

Future
expansion
Future expansion

API Facade
Developer
experience

Future expansion
MARSHA
Marketing DB
Property DB
Main components of Marriott's current architecture:
Marriott's Central repository system which has been up and running for 30 years.

Reflects OTA standards effectively.
A stand alone DB containing reward points data for each customer profile.
A stand alone DB containing properties information.
Prior to 2006, calls to Marsha, Property and Marketing databases were being made separately by our partners. This involved a considerable amount of overhead for the partners to access Marriott's complex internal systems.
However, the process of communicating with our internal systems has become much more consistent and efficient with the development of SOAP services.
SOAP gave us a consistent communication protocol and the performance of these services have been robust till date.
However..
Problems associated with SOAP services:
The services are very well documented, with a 30 page specification document describing each service.
The learning curve associated with the use of SOAP services is steep.
There is still inconsistency in the data between the three databases.
Moreover SOAP services with XML implementation are now antiquated as they are heavy weight and expensive to parse when compared to more robust JSON implementation. (Refer to the next slide for a sample code snippet showing the robustness of JSON over XML)
The API Facade
-
Providing a simple interface to our complex subsystems
The REST API is not only useful for the mobile app developers, but it also provides an easy way to integrate with the existing websites.
It can be assumed to be a kind of Mobile middleware, thus acting as a mask to the underlying Marriott's architecture.
The next slide shows our proposed API Facade pattern.
Introducing APIs:
An API is now considered as cornerstone of the next iteration of business development, a holy grail for establishing and maintaining business relationships in a 24/7 digital economy.
A decade ago, businesses were still working to understand the importance of having a website for doing business. Today, businesses are beginning to understand the similar importance in having an API.
What technology goes into it?
The most popular approach to delivering web APIs is REST (Representational State Transfer)
A Rest API takes the already available data and functionality and makes them available through a programmatic API, that both mobile and web applications can use.
The API instead of returning data in HTML, now returns it in two formats: XML or JSON.
Developers or internal partners can take this easily consumable data and use it to build web or mobile applications.
SOAP XML is focused on providing named operations, each implementing some business logic, accessible through different interfaces. Therefore, SOAP services are not consistent in style or format across service providers.
SOAP Vs REST API
Where as REST focuses on named resources accessible through a single consistent interface.
The following slide shows the REST API road map for two of the Marriott's resources.
The Big Picture:
Code sample for Property Info Web Service (PIWS) "Transportation" object:
JSON simplification of PIWS Transportation object:
"transportation": [
{
"name": "Train Station",
"description": "Penn Station",
"distance": "1 mi S",
"url": "www.amtrak.com/stations/nyp.html"
}
]
The above REST-JSON code is a lot smaller and less bloated, thus providing the following advantages:
-Efficiency
It is easier to parse the data and to extract and convert it, so requires much less from effort the CPU of the client.
-Caching
Provides improved response times and server loading due to support from caching
-Implementation
The interfaces are much easier to design and implement.
Why go public with API?
Going public attracts new OTA and new developers.
It helps us to expand our brand's reach, by making us visible in all the customer accessible avenues.
API management offers us advantages of controlling and monitoring the users of our services and thus protecting our web content against and screen scrapers.
Future expansion to Marriott's architecture:
If changes are made to the architecture in the future, (for eg: if the Available inventory and Pricing systems are moved out of MARSHA), no changes absolutely are required for the API design and code.
If architecture remains the same, but if changes are made to any one of the services, then only the back end (data) of the API needs some tweaking; while the developers remain oblivious to the changes, as the front end still remains the same.
Thus, the API facade pattern we proposed is clearly scalable.
Future changes to the public API:
When a new API needs to be added, then a new service orchestration will be required.
Developer experience:
Building an API that not just serves the needs of the business but also delights developers with a seamless and effortless developer expereince is the key.
Because the developer is actually a business user but with the persona of a developer.
For this we provide the minimum viable resources in the API, that have the ability to support all the HTTP actions which developers need.
Placeholder for RV info and example of rates and search
MARSHA
Marketing systems DB
Property DB
ACP
VIGNETTE
Service orchestrations
Data objects
SOAP services
SOAP services
SOAP services
SOAP services
SOAP services
API Facade Conceptual Diagram:
Service orchestration BPMN patterns:
Psuedo code for Delete reservations:
Also the error codes and messages clash across SOAP service providers.
However, offering a Public API requires a full range of security measures to be taken to protect Marriott's resources.
The new service orchestration may or may or not be using the existing data .
Explaining the API Facade:
The above API facade pattern is a simple and intuitive interface that hides to the maximum extent possible the complexity stemming from the challenges of integrating the Restful JSON APIs with our SOAP XML services.
Three key steps in the design of the facade are:
1. Reorganize the data returned from the collection of atomic services into a minimum viable set of Resources.

2. Define a single data model of each resource, in JSON format.

3. Define a set of RESTful APIs to interact with the resources. Requests take the form of simple Uniform Resource Identifiers (URIs). Responses always conform to the singular JSON data model.

Explaining the API Facade:
(contd)
MARSHA
Marketing systems DB
Property DB
ACP
VIGNETTE
Service orchestrations
Data objects
SOAP services
SOAP services
SOAP services
SOAP services
SOAP services
API Facade Conceptual Diagram:
Full transcript