Email
Like
Liked ×
Save
Private Content
Embed
Loading embed code…
We have emailed the verification/download link to "".
Login to your email and click the link to download the file directly.

To request the link at a different email address, update it here. Close
Validation messages. Success message. Fail message.

Check your bulk/spam folders if you can't find our mail.
Loading

+ Follow

API Design Tour: Dell

by Apigee on Oct 25, 2012

1,486 views

Accessibility

View text version

Upload Details

Uploaded via SlideShare as Microsoft PowerPoint

Usage Rights

File a copyright complaint

7 Embeds 681

http://blog.apigee.com	470
http://apigee.com	155
http://blog.edit.apigee.net	21
http://feeds.apigee.com	19
http://edit.apigee.net	13
http://blog.local	2
http://www.hanrss.com	1

More...

Statistics

Likes: 1
Downloads: 22
Comments: 1
Embed Views: 681
Views on SlideShare: 805
Total Views: 1,486

1–1 of 1 previous next

Apigee at Apigee
7 months ago
Are you sure you want to

Creative Commons Attribution-Share Alike 3.0 United States License
Dell Inc. provides integrated technology solutions in the information technology (IT) industry worldwide
Opportunity: Monetize Dell services, solutions, capabilities through API Tool for Dell to open our portfolio of solutions to our customersBuild on success and expand API services to generate revenueEnable high ROI programsStarted as an innovation center incubation project to explore the best possible options to connect partners and customers with valuable Dell internal services.
Our target developers are mainly internal and partners. Eventually we want to open our API’s to external “man on the street” developers. But currently we find a lot of opportunity with exposing it to our partners and internal developers through “Dell Hackathons”
Talking points: Support services API’s - Order status, case management, Support historyMobile API’sCommunity API’sCompany acquisition -> taking orders internationally and calculating taxes. Integrate order processing capabilities. Exposed tax calc as an API.
We follow the “pragmatic REST” philosophy .Currently most of our internal services are all SOAP based and we sometimes do spend cycles RESTifying them and externalize.There is a push to ensure that internal services are designed with REST principles so they can be exposed externally with minimal effort, unlocking their value faster.
The ones that have generated the most discussion are those around defining service levels and throttling limits. We have found that it is an ever changing definition, getting refined with over time with new API and associated clients. We need to adapt the service levels to the needs of our clients and the constraints of our internal services, which has been a challenging, but a nice intellectual exercise.The other is around versioning and how do we manage communication around internal service version changes and how it affects clients usign our API’s
Handles as part of query string parameters in the header
If metadata is requested, we can return it as part of the response header or modify the response body as needed by the client.
Counting is normally not supported unless it is supported by the internal service of the relevant API. Currently we have it only for one of our support services.
Currently as many other folks, we mainly use GET, as the request is to provide information from our services, like Order Status. We also use POST for some of our API methods where it is necessary to provide update or create new information. For e.g., community posting, or creating a new issue ticket.In some instances, we use POST slightly differently due inherent limitations with GET for our needs. We use POST in some cases to do a GET or Search.
Typically we try to adopt the standard POX convention without namespaces for most as its easier for our users. The data contract though, will likely be different for every API.
Version information is part of the URI. Its mandatory we manage versions appropriately since our internal services could drastically change with releases. We provide support for two versions at a time, with appropriate deprecation policy defined and communicated. Most of our versions are long lived, and it can take up to a year or more to deprecate an earlier version.
We endeavor to keep our URI intact for changes. All our changes get absorbed within the application, so the user does not see any changes that they need to adapt to. If there is a major change like a platform upgrade (which is rare), we do plan to deprecate the older versions. We try to give users appropriate notice and keep our communication channels open till the process is complete.
Currently we do not handle search in any of our API’s.
NOTES:Developer portal is currently internalAssetinfo is an example of a support services API
Currently all our authentication is handled through API Keys. We are starting to use Dell account authentication for some of our clients. We are planning to offer OAUTH authentication as soon as the internal service teams start supporting it in production (currently in testing).
We do not have an SDK out there currently. We do provide code samples including request/response parameters for all our API’s
We ensure that performance is maximized by keeping the functionality at the API layer to a minimum, if it can all be handled by the underlying service. For example that was the case in one of our recent implementations and we just let the data pass through the API layer with minimal/no impact performance impacts in servicing the requests. In some instances we might have to do some processing on the data fetched from the internal services, in these instances we endeavor to separate the data fetch operation from the user request one so we can keep performance impacts to the minimum. The trade-off is slightly stale data.
Internal service readiness. Working closely with internal service teams to ensure they are on boardManaging limits on service Vs. client expectations of the service. Defining appropriate service levels and planning for growth, particularly on the infrastructure sideHaving an appropriate support and communication strategy in place before releasing the API’s in to the wild.Defining process for service level upgrade and associated costs.Don’t forget marketing your API’s and the good work within the company to get people thinking of how they can leverage what has been created or add to the mix.

1 Like

supertoy2015 Tags api 7 months ago

API Design Tour: Dell Presentation Transcript

API Design Tour:DellRound Rock, Texas, USABrian Mulloy Apigee@landlessness @apigee
groups.google.com/group/api-craft
youtube.com/apigee
slideshare.net/apigee
@Dell@sbelekar @ravichittur @ctboyland@apigee@landlessness
What does your company do?
Why do you have an API? How did it get started?
Who are your target developers? Internal?Partners? Open?
How is your API used?
What is your API design philosophy?
Which aspects of the API design have generatedthe most discussion internally and externally?
How do you approach URI design?URI Examples/content/customize/v2/{app_root}/{file}.(xml|json)/support/assetinfo/v2/summary.xml?svctags=2sqs3bsResponse<?xml version="1.0" encoding="utf-8"?><GetAssetSummaryResponse xmlns=http://tempuri.org/><GetAssetSummaryResult xmlns:a="http://schemas.datacontract.org/2004/07/Dell.AWR.Domain.Asset"xmlns:i="http://www.w3.org/2001/XMLSchema-instance"> <a:Faults/> <a:Response xmlns:b="http://schemas.datacontract.org/2004/07/Dell.AWR.Domain.Asset.Mobile"> <b:DellAsset> <b:AssetParts> <b:AssetPart> <b:PartDescription>Processor,T9550,2.66,6MB,Core Penryn,35W,E0</b:PartDescription> <b:PartDescriptionRefined>Processor, T9550, 2.66, 6MB, Core Penryn, 35W, E0</b:PartDescriptionRefined> <b:PartNumber>H185K</b:PartNumber> <b:Quantity>1</b:Quantity>
How do you handle multiple formats? What is yourdefault?/support/assetinfo/v2/summary.xml/support/assetinfo/v2/summary.json XML is the default.
How do you handle pagination?Limit & Offsethttps://sandbox.api.dell.com/support/assetinfo/v2/summary.xml?svctags=2sqs3bs&limit=20&offset=1
How do you handle metadata in your responses?
How do you handle counting?
How do you approach HTTP Verbs?
Which convention do you use for responseattribute names?
How do you handle errors?HTTP Status Codes200 301 302 400 500Typical Error Response Template<Code>eAPI-40420</Code><Message>Resource Not Found</Message><Reason>Failed to find the resource: ${Config File Name} for API:${APIName}</Reason><Source>Gateway</Source>
How do you handle versions?/support/assetinfo/v2/header.{xml/json}
How do you handle backwards compatibility,deprecation and obsolescence?
How do you handle search?
What design flourishes are you proud of?
What changes have you made to your designbecause it was confusing for developers?
What are your top level sub domain names foryour API and your developer portal?http://api.dell.com/http://developer.dell.com/ Currently API & developer portal are internal only.
How do you handle authentication andauthorization?
How do you handle SDKs and code libraries?
How have performance considerations impactedyour API design?
What challenges can API Teams anticipate as theyimplement their API initiatives?
What is on your API roadmap?
What else should we know about your API?
Questions from audience?
THANK YOUSubscribe to API webcasts at:youtube.com/apigee
THANK YOUQuestions and ideas to:groups.google.com/group/api-craft
THANK YOUContact me at:@landlessnessbrian@apigee.com@apigee

API Design Tour: Dell

by Apigee on Oct 25, 2012

Accessibility

Categories

Upload Details

Usage Rights

7 Embeds 681

Statistics

API Design Tour: Dell Presentation Transcript

Let LinkedIn power your SlideShare experience

Let LinkedIn power your SlideShare experience

Customize SlideShare content based on your interests

Keep up to date when your LinkedIn contacts post on SlideShare