Architecting &Building Scalable, Secure Web API

1. SHAKIL AKHTAR
Architecting & Building Scalable,
Secure Web API

2. About Me…
² Oracle Certified Master Java Enterprise Architect
² TOGAF 9 Certified Enterprise Architect
² AWS (Amazon Cloud) Certified Solutions
Architect
² Spring Source Certified Enterprise Integration
Specialist
² Apache Phoenix Contributor
² Member AEA(Association of Enterprise
Architects)
² Cloudera Certified Developer For Hadoop
² SCJDWS
² SCWCD
² SCJP

3. Agenda
² Technical approach on designing & developing enterprise
scaled reliable Web API.
² Discussion on various parameter consideration while
architecting robust RESTful services.
² Q&A

4. A Quick Rundown
² API overview
² API Methodologies
² Technical Considerations for API
² Services Scalability
² Security Methodologies
² Best practices

5. What are APIs?
² API = Application Programming Interface
² Business Capabilities exposed over internet for applications to
use
² An API is external facing
² Web Service = API that operates over HTTP
² In this presentation,API == REST

6. Why Create an API?
² Extend your product reach
² Encourage mashups
² Expose your data programmatically
² Connect with developers

7. API Success Stories
² Twitter
² Facebook
² Amazon Web Services
² Linked-in
² Salesforce API
² -- many more

8. Discovering and Describing APIs
² API description to be extremely useful and meaningful
² APIs need to be published somewhere to be discovered
² A comprehensive API management platform needs to have at
least three main components: a publisher, a store, and a
gateway
API Management Platform

9. API Centric Architecture

10. API Tier Architecture

11. Popular Methodologies
² REST
² SOAP
² XML RPC

12. Why REST?
² Scalability
² Generality
² Independence
² Latency(Caching)
² Security
² Encapsulation

13. Key Design Principles for APIs

14. Key Design Principles
² Designing APIs for Specific Audiences
§ Designing for Developers
§ Designing for Application Users
² Best Practices for API Design
§ DifferentiateYour API
§ MakeYour API Easy to Try and Use
§ MakeYour API Easy to Understand
§ Don’t Do Anything Weird
§ Less Is More
§ Target a Specific Developer Segment

15. Technical Consideration
for API Design

16. Technical Considerations for API Design
² REST
§ Pure REST
• follows the dictates of Fielding’s dissertation
§ Pragmatic REST
• follow certain REST principles, but not all of them
• Easy to learn and navigate and represent the majority of public APIs
§ Pragmatic RESTful Principles
• uses the best parts of the RESTful concept

17. Example: Designing with Pragmatic REST
² The wrong way to REST
Task Operation URI
Insert new item into the
cart
POST http://api.shopping.com/InsertNewItem
Delete item from the cart POST http://api.shopping.com/DeleteItem
List everything in the cart GET http://api.shopping.com/ListCart?
cartId=X
Get an item in the cart GET http://api.shopping.com/ShowItem?
cartId=X&itemid=Y
Delete the whole cart POST http://api.shopping.com/DeleteCart

18. Example:
² Pragmatic RESTful Shopping Cart
² Something REST needs a Rest
² XML vs. JSON
Task Operation URI
Insert new item into the
cart
POST http://api.shopping.com/cart/cartName
Delete item from the cart DELETE http://api.shopping.com/cart/
cartName/item/itemName
List everything in the cart GET http://api.shopping.com/cart/cartName
Get an item in the cart GET http://api.shopping.com/cart/
cartName/item/itemName
Replace an entire item PUT http://api.shopping.com/cart/
cartName/item/itemName
Delete the whole cart DELETE http://api.shopping.com/cart/cartName

19. Versioning and API Design
² Url
§ https://api.mycomp.com/v1
² Media Types
§ application/json+foo;application&v=1
² Having a Mediation Layer
² Taking the Plunge: GoingVersionless

20. Designing Infrastructure for APIs
² Data Center or Cloud?
² Caching Strategies
² Controlling API Traffic
§ Business-Level Traffic Management
• Quotas
• Throttling
§ Operational Traffic Management
• Spike Arresting
§ API Gateways
• Approaches to API Gateways in the Cloud

21. Scalability

22. Scalability Layers
Internet
Enterprise infrastructure
and integrations
Platform
Enterprise Server
Enterprise Applications
• External Network
• User Devices
• Network and hardware
• Database
• Services
• Operating System
• Cloud Platform
• Web Server
• Application Server
• Application Modules
• APIs

23. Dimensions of Scalability
² Load scalability
² Functional Scalability
² Integration Scalability
² Geographic Scalability

24. Services Scalability
² Designing Scalable Services
§ Granularity of Service
§ Services per business process
§ Lightweight service
§ Stateless nature
§ Asynchronous invocation
§ RESTful services
§ Service layer caching
² Architecting scalable services infrastructure
² Clustered server configuration of web services
clustered server
configuration for
services

25. Distributed Clustered ESB Configuration for Services

26. Scaling HTTP
² Statelessness and scalability
² ETags/LastModified
² Caching and proxies
² HEAD
² “Expect: 100-continue”
² Batch operations
² Transactions & Compensation

27. Stateless client/server approach
² All communication is stateless
² Session state is kept on the Client!
§ Client is responsible for transitioning to new states
§ States are represented by URIs
² Improves:
§ Visibility
§ Reliability
§ Scalability
Link state transitions for a coffee
order

28. ETag Header
² Resources may return an ETag header when it is accessed
² On subsequent retrieval of the resource, Client sends this
ETag header back
² If the resource has not changed (i.e. the ETag is the same), an
empty response with a 304 code is returned
² Reduces bandwidth/latency

29. ServerClient
Client Server
ETag Example
HTTP/1.1 200 OK
Date: …
ETag: "3e86-410-3596fbbc"
Content-Length: 1040
Content-Type: text/html
…
HTTP/1.1 304 Not Modified
Date: …
ETag: "3e86-410-3596fbbc"
Content-Length: 0…
GET /feed.atom
Host: www.myhost.com
…
GET /feed.atom
If-None-Match:
"3e86-410-3596fbbc"
Host: www.myhost.com
…

30. Revalidation and Conditional GETs
² Last-Modified
§ Represent timestamp of the data sent by the server
§ Do conditional get call using If-Modified-Since
HTTP/1.1 200 OK
Content-Type: application/xml
Cache-Control: max-age=1000
Last-Modified:Tue, 15 May 2009 09:56 EST
<customer id="123">...</customer>
GET /customers/123 HTTP/1.1
If-Modified-Since:Tue, 15 May 2009 09:56 EST

31. Client Server
LastModified Example
HTTP/1.1 200 OK
Date: …
Last-Modified: Sat, 29 Oct
1994 19:43:31 GMT
Content-Length: 1040
Content-Type: text/html
…
HTTP/1.1 304 Not Modified
Date: …
Last-Modified: Sat, 29 Oct
1994 19:43:31 GMT
Content-Length: 0
GET /feed.atom
Host: www.acme.com
…
GET /feed.atom
If-Modified-Since:
Sat, 29 Oct 1994
19:43:31 GMT
Host: www.myhost.com
…

32. Scalability through Caching
² A.k.a. “cache the hell out of it”
² Reduce latency, network traffic, and server load
² Types of cache:
§ Browser
§ Proxy
§ Gateway
Web Caches

33. How Caching Works
² A resource is eligible for caching if:
§ The HTTP response headers don’t say not to cache it
§ The response is not authenticated or secure
§ No ETag or LastModified header is present
§ The cache representation is fresh
² A good post : http://www.mnot.net/cache_docs/

34. Is your cache fresh?
² Yes, if:
§ The expiry time has not been exceeded
§ The representation was LastModified a relatively long time ago
² If its stale, the remote server will be asked to validate if the
representation is still fresh

35. Concurrency
² When many client try to updated a resource
² Conditional PUT or POST
A conditional PUT request

36. Scalability through URLs and
Content-Types
² Information about where the request is destined is held
outside the message:
§ Content-Type
• application/purchase-order+xml
• image/jpeg
§ URL
§ Other headers
² Allows easy routing to the appropriate server with little
overhead

37. HEAD
² Allows you to get meta data about a resource without getting
the resource itself
² Identical to GET, except no body is sent
² Uses:
§ Testing that a resource is available
§ Testing link validity
§ Learning when a resource was last modified
HEAD /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible;
MSIE5.01;Windows NT)
Host: www.mycomp.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server:Apache/2.2.14 (Win32)
Last-Modified:Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Vary:Authorization,Accept
Accept-Ranges: bytes
Content-Length: 88
Content-Type: text/html
Connection: Closedclient
server

38. 100 Continue
² Allows client to determine if server is willing to accept a
request based on request headers
² It may be highly inefficient to send the full request if the server
will reject it

39. 100 Continue
Client sends initial headers and:
• Expect: 100-continue
• nn
Server sends:
• 100 Continue
• n
Client sends full message body

40. Transactions
² The web is NOT designed for transactions
§ Client is responsible for committing/rolling back transactions, and client
may not fulfill responsibilities
§ Transactions can take too long over the web and tie up important
resources
² In general, it is much better to build in application specific
compensation for distributed services

41. So you really want transactions…
² People sometimes use HTTP for transactions
² Notable example: SVN
² It is possible to model a resource as a transaction
§ POST – create a new transaction
§ PUT – send “commit” state to transaction
§ DELETE – rollback the transaction

42. Batch Operations
² How do we manipulate multiple resource states at the same
time?
² Options:
§ Use HTTP connection pipelining
• Broken by some firewalls

43. Scalability Best Practices
² Stateless session
² Lightweight design
² On-demand data loading
² Resource pooling
² Using Proven technologies
² Optimal enterprise integrations

44. Scalability Best Practices Cont.
² Scalability by design
² Latency and throughput optimization
² Early runtime application analysis
² Avoid blocked waits
² Rules engine-based business logic

45. Security

46. API Security Architecture

47. Security By Design
² Design Challenges
§ User Comfort
§ Performance
§ Weakest Link
§ Defense in Depth
§ Insider Attacks
§ Security by Obscurity
² Design Principles
§ Least Privilege
§ Fail-Safe Defaults
§ Economy of Mechanism
§ Complete Mediation
§ Open Design
§ Separation of Privilege
§ Least Common Mechanism
§ Psychological Acceptability

48. Security By Design
² CIA
§ Confidentiality
§ Integrity
§ Availability
² Security Controls
§ Authentication
§ Authorization
§ Nonrepudiation
§ Auditing
² Security Patterns

49. Securing REST

50. REST Security
² None built in
² Encryption over HTTPS
² Left to the implementer
² Error handling left to implementer

51. Security Mechanism
² OAuth
² BasicAuth
² API Keys

52. OAuth
² OAuth description points

53. BasicAuth
² Passes a username and password with the request
² Defined by the HTTP specification
² BasicAuth Do’s
§ SSL is a must
• Username / Password is transmitted in clear text
• Base64 encoded, but not encrypted

54. BasicAuth Pros & Cons
² Pros
§ Client requests are easy
• Part of nearly every HTTP request library
§ Server setup is easy
• Use existing BasicAuth credentials
² Cons
§ Requires a username and password for a user
§ Credentials are not, by default, encrypted
§ Requires username and password to be embedded in client code

55. Access Keys
² Not based on any standard
² Implementation requirements are up to the service provider
² Keys -> signatures

56. Access Key Basics
² Part of URL
http://xyz.com/api?key=23sdbk32
² Sign request with key instead of passing it in URL
² Use params + shared secret as signature

57. Signed Request Workflow
Client
Server

58. Access Keys Pros& Cons
² Pros
§ Easy to generate keys and distribute them
§ Typically removes the need to transfer username and password in
raw form
§ Signed requests prevents altering parameters
² Cons
§ Unsigned
• Must embed them in code
• SSL is not required, so will (by default) transfer in plaintext
§ Signed
• Encryption is scary....ish

59. Best Practices
² Rate Limiting
§ Keeps API access in check
§ Authenticated and Unauthenticated calls should be subject to rate limiting
§ Have a standard, application wide rate limit
§ Allow that limit to be overridden on a per user, per application basis
² Access Control
§ Treat API endpoints just as service endpoints in your application
§ Have a standard API access site wide
• Allow override on a per-user, per application basis
§ Allows you to roll out features to a select group or user
² Error Handling
§ Set appropriate HTTP headers
§ Provide viable, valid error messages
§ Log errors for the API too
§ Have a standard error response object for all methods, including authentication
² API Domain
² API Keys

60. Best Practices Cont.
² Identifier
² Query Injection
² Redirects and Forwards
§ Avoid redirects and forwards if possible
§ If used, validate the value and ensure authorized for the current
user
² TLS
§ Use TLS for everything
§ Cookies: set the ‘secure’ and ‘httpOnly’ flags for secure cookies
² Configuration
² Storage

61. Summary
v Architecting Web API
v Building API strategies
v Scaling API Considerations
v Securing your API
v Best Practices

63. ThankYou!
© Shakil Akhtar