• Save
LAJUG Napster REST API
Upcoming SlideShare
Loading in...5
×
 

LAJUG Napster REST API

on

  • 2,187 views

I presented our Napster REST API at the LAJUG

I presented our Napster REST API at the LAJUG

Statistics

Views

Total Views
2,187
Views on SlideShare
2,181
Embed Views
6

Actions

Likes
0
Downloads
0
Comments
1

1 Embed 6

http://www.linkedin.com 6

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

11 of 1

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • Hi Stephen,

    Can you use the napster API for commercial use in an iphone app?

    thanks
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    LAJUG Napster REST API LAJUG Napster REST API Presentation Transcript

    • Napster REST API
    • Napster
      We are a Best Buy company
      We are the best deal on the internet
      $5 a month for 5 downloadable MP3s + Unlimited streaming of 10million tracks
      We have a brand new site
      http://music.napster.com
      We have a live REST API since January
      http://developer.napster.com
      We are actively working on putting the music on
      Phones, Bluray Players, IPTVs & pretty much all the connected devices
      We are also working with developers to create music apps
      one app so far (http://twt.fm)
      The API team is a small agile team of 6
      We started the project in July and released the first version for the CES at January
    • Agenda
      What’s REST?
      Quick tutorial on REST
      Four guiding principles of REST
      JAX-RS
      Specification
      Implementations
      Napster REST API Demo
      Napster REST API Architecture
      Security
      Response Format
      Caching
      Error Handling
      Versioning
      Continuous Integration
    • Agenda
      What’s REST?
      Quick tutorial on REST
      Four guiding principles of REST
      JAX-RS
      Specification
      Implementations
      Napster REST API Demo
      Napster REST API Architecture
      Security
      Response Format
      Caching
      Error Handling
      Versioning
      Continuous Integration
    • REST
      Representational State Transfer
      www.library.com
      User requests a Resource using URL
      http://www.library.com/books
      /books
      /175 – Effective Java 2nd – Josh Bloch
      /952 – Windows MFC – Jeff Prosise
      /319 – C++ Programming – Bjarne Stroustrup
      /367 – UML Distilled – Martin Fowler
      /361 – Beginning Oracle – Tom Kyte
      /245 – Doman Driven Design – Eric Evans
      /298 – Lucene in Action – Erik Hatcher
      /395 – Ext GWT RIA – Grant Slender
      /392 – Tomcat 6 – Vivek Chopra
      /281 – RESTful Services – Sam Ruby
      A Representation of the Resource is returned, and thus placing the client application in a State.
      The Representation contains hyperlinks to other related Resources (individual books).
      User clicks a hyperlink on the page
      A Representation of another Resource is returned, and
      thus causing a Transfer of client application State
      This constant Transfer in client’s State through various Representations is
      “Representational State Transfer”
    • REST
      Roy Fielding introduced REST Architectural Style for distributed hypermedia systems
    • What is an ‘Architectural Style’?
      An Architectural style is way of classifying architectures based on a set of “architectural constraints”
      Gothic Architecture:
      The ‘Clustered Columns’, ‘Pointed
      Ribbed Vaults’ and the ‘Flying
      Buttresses’ makes this a Gothic
      Architecture
    • REST Architectural Style Constraints
      • Client-Server – clients separated from server by uniform interface
      • Stateless – no client context stored on server
      • Cacheable – responses must define themselves as cacheable or not
      • Layered System – intermediary servers for load balancing, shared caches and enforce security
      • Code on Demand (optional) – customize client functionality by transferring logic (applets or javascript)
      • Uniform Interface – (next slide)
    • Guiding principles of REST Interface
      • Identification of Resources
      • Individual resources are identified in requests using URIs
      • Manipulation of Resources
      • Resources are manipulated using a fixed set of four create, read, update, delete operations: PUT, GET, POST, and DELETE
      • Self descriptive messages
      • Each message includes enough information on how to process the message. Responses also indicate their cacheability.
      • Hypermedia As The Engine Of the Application State (HATEOAS)
      • Related resources should be identified in the representation returned by providing their URIs
    • What do we gain by going REST?
      Conforming to the REST architectural style, will enable a distributed hypermedia system to have desirable emergent properties such as performance, scalability, simplicity, modifiability, visibility, portability and reliability.
      The largest known implementation of a system conforming to the REST architectural style is the WWW
    • SOAP vs REST
      SOAP Coffee Request
      POST /askCoffeePolitelyHTTP/1.1
      Host: www.coffee.com
      Content-Type: application/soap+xml; charset=utf-8
      Content-Length: 100
      <?xml version="1.0"?>
      <soap:Envelope
      xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
      soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
      <soap:Bodyxmlns:m="http://www.coffee.com/askCoffeePolitely">
      <m:GetCoffee>
      <m:NumberOfCoffees>1</m:NumberOfCoffees>
      </m:GetCoffee>
      </soap:Body>
      </soap:Envelope>
      REST Coffee Request
      GET /askCoffeePolitely/coffee?numberOfCoffees=1 HTTP/1.1
      Host: www.coffee.com
    • SOAP vs REST
    • Big advantage of REST
      Your REST API
    • Agenda
      What’s REST?
      Quick tutorial on REST
      Four guiding principles of REST
      JAX-RS
      Specification
      Implementations
      Napster REST API Demo
      Napster REST API Architecture
      Security
      Response Format
      Caching
      Error Handling
      Versioning
      Continuous Integration
    • JAX-RS Specification
      Defines a set of Java APIs for development of Web Services build according to the REST architectural style.
      Goals:
      POJO Based - Provides a set of annotations and associated classes/interfaces that can be used with POJOs to expose them as Web Resources.
      HTTP Centric - Provide clear mappings between HTTP & URI elements and corresponding API classes and annotations
      Format Independent - Provide necessary pluggability of content types
      Container Independent - Artifacts using the API will be deployable in a variety of web-tier containers
    • JAX-RS Implementations
      (as quoted by some one else)
      there's a strange phenomenon regarding buses: you wait ages for one, then three come along at once! The same seems to be true for JAX-RS implementations. At the moment we have:
      Restlet
      probably the first REST framework, which existed prior to JAX-RS
      CXF
      which is a merger between XFire and Celtix (an Open Source ESB, sponsored by IONA and originally hosted at ObjectWeb)
      Jersey
      the JAX-RS Reference Implementation from Sun
      RESTEasy
      JBoss's JAX-RS project
    • Agenda
      What’s REST?
      Introduction
      SOAP vs REST
      JAX-RS
      Specification
      Implementations
      Napster REST API Demo
      Napster REST API Architecture
      Security
      Response Format
      Caching
      Error Handling
      Versioning
      Continuous Integration
    • To get started on the API
      • Generate an API Key from developer portal http://developer.napster.com
      • Signin using your napster account (or) Signup for a new account
      • Generate an API Key from [Keys & Account Info] section
      • Use this Excel sheet
      • Napster_API_Test_Console_Excel.xls
      • and copy/paste your API Key into the apiKey cell
      • Create a SessionKey
      • by clicking the CreateSession
      • and copy/paste your Session Key into sessionKey cell
      • Now you can access all the REST API Services (Resources) and get their XML/JSON representation
    • REST API Services
      Public API
      • Search
      • Genre
      • Album
      • Artist
      • Track
      • Radio
      • Automix
      • Napster Playlists
      • Staff Picks
      • Image
      • Security
      Private API
      • Security (login)
      • User
      • Track (playTrack)
      • Billboard
      Full API documentation is at the Portal  http://developer.napster.com/docs/
    • Agenda
      What’s REST?
      Introduction
      SOAP vs REST
      JAX-RS
      Specification
      Implementations
      Napster REST API Demo
      Napster REST API Architecture
      Security
      Response Format
      Caching
      Error Handling
      Versioning
      Continuous Integration
    • Napster REST API Architecture
      Security
      Caching
      Response Format
      Error Handling
      Versioning
      Continuous Integration
    • Quick note:
      We put our Request details in ThreadLocal variables so that we don’t have to pass it around in method parameters
      • Since tomcat reuses threads we clear it before a request is done
    • Security
      Caching
      Response Format
      Error Handling
      Versioning
      Continuous Integration
    • Security – API Key / Session Key
      • API Keys are
      • Generated by Developer Portal per Application
      • To be kept “SECRET”
      • To be used through Secure protocol (https://) only
      • Unchanging, it never Expires
      • Session Keys are
      • Generated by the Applications by calling “CreateSession” or “Login” APIs
      • Validated for all incoming API requests (except CreateSession, Login)
      • Can be used in an Unsecured protocol (http)
      • Good for only 6 hours, it Expires
    • Security Model
      • Developers or Partners can have one of more API Keys, each one mapped to an application
      • For Selected Developers or Partners their API
      Key is given access to
      • One or more Private APIs
      • One or more Media Types (MP3, MP4, AAC, etc)
      API
      Developer/Partner
      API Keys
      Private APIs
      Media Types
    • Interceptor to validate SessionKey
    • Interceptor to Authorize Restricted Services
    • Security
      Caching
      Response Format
      Error Handling
      Versioning
      Continuous Integration
    • REST Service Method
    • Model class with JAXB Annotations
    • Utility to build XML/JSON responses
    • Response Output
      We currently support XML, JSON & JSON-P formats
    • JSON-P
      • Is used by for our JavaScript wrapper API
      • http://developer.napster.com/js/api.js
      • To over come cross domain restriction with this hack:
      • varurl = http://api.napster.com:8080/rest/1.1/genres/1 ?format=json&callback=displayGenreDetails&sessionKey=BPGVjLGpzc
      • Yes, it’s wrong – but it seems to be the popular approach to get json contents from public APIs
    • We also support “partial responses”
    • Security
      Caching
      Response Format
      Error Handling
      Versioning
      Continuous Integration
    • Utility to build XML/JSON responses
    • Utility refactored to set Cache Headers
      New method
      New method
    • Response Cache Headers
      Cache Headers
    • Some observations…
      • Implementing HATEOAS can hurt when Caching
      • If the hyperlink in your responses contain session tracking information then you can’t cache this and reuse for other sessions
      • So, make sure the Cacheable responses don’t carry any session specific information
      • Sometimes, you don’t know the browser using your API
      • The API opens the door to many different device browser platforms like Konfabulator (the Yahoo Widget Library) or other embedded proprietary browsers
      • So, its probably a good idea to set “downstream-ttl” to value much shorter than the “max-age” when Caching on the Edge (just a thought)
    • Security
      Caching
      Response Format
      Error Handling
      Versioning
      Continuous Integration
    • The Exception Class
      Root Exception Class
      Sub class
    • The Error Class
    • The Exception Mapper
    • Error Handling / Error Format
      XML
      JSON
    • Error Handling
      • We don’t have Application Error Codes, we map application errors to the closest HTTP Error Code.
      • We use actual HTTP Error Codes with an appropriate error message in the response
    • Security
      Caching
      Response Format
      Error Handling
      Versioning
      Continuous Integration
    • First, we came up with some questions…
      • Do we even need versioning?
      • When do we make a minor version?
      • When do we make a major version?
      • How long are we going to be backward compatible?
      • How do we guarantee that this new fix is not a breaking change?
      • Are there any external factors that could affect our older versions?
    • Then, some answers…
      • Do we even need versioning?
      • Sadly, yes
      • When do we make a minor/major version?
      • We are going to try hard to NOT make new versions by
      • defining the response tag elements right the first time
      • adding newer elements to the tail end of tag
      • We make a new version only when we have a breaking change
      • How long are we going to be backward compatible?
      • Let’s shoot forever, if we are lucky enough we’ll drop older versions
      • How do we guarantee that this small fix doesn’t break anything?
      • 70 APIs, 2 Versions, 2 Formats, 5 Different Country Codes
      • that’s 70 x 2 x 2 x 5 = 1400 tests (a little exaggeration there)
      • Are these any external factors that could affect our older versions?
      • You betcha… 
    • So, it came down to…
      • Having a simple versioning design
      • Keeping all the code base in one place without any branching so that its easier to code, maintain, refactor, debug
      • Having a “solid” CI Test Suite to test every little change
    • Versioning Implementation
      GenreRestServiceV10 Implementation
      @Override
      • getGenres(){
      }
      @Override
      • getTopAlbumsByGenreId(int genreId){
      }
      GenreRestService Endpoint
      /(1.0|1.1)/genres
      • getGenres()
      /(1.0)/genres/{genreId}/albums
      • getTopAlbumsByGenreId(int genreId)
      /(1.1)/genres/{genreId}
      • getGenreById(int genreId)
      3
      1
      GenreRestServiceV11 Implementation
      @Override
      • getGenreById(int genreId){
      }
      3
      2
      Service Version Map
      Key
      Value
    • The Endpoint class
    • Napster REST API Architecture
      Security
      Caching
      Response Format
      Error Handling
      Versioning
      Continuous Integration
    • Continuous Integration
      API QA
      Remote
      API_DEV
      API_QA
      API_AUTO_STAG
      API_AUTO_PROD
    • SoapUI to write the test suites
    • Each version has its own set of tests
    • ANT Contrib to run the SoapUI projects
    • Targets to run dev, qa, stag & prod tests
    • Hudson to build, deploy and test…
    • SoapUI produces ton of log files
    • A “tiny” little bash script…
      • To recursive find grep SoapUI log files directories
      • Make a list of failed test cases (*FAILED.txt files)
      • Prepend the server URL to make clickable hyper links
      • Email the Team
      Subject : API_DEV - SOAPUI FAILED TESTCASES
      Email :
      1 Test Cases Failed in 1.0 Services
      ===========================================
       
      http://ci01.napster.com:8080/hudson/job/API_DEV/ws/NapsterApi/test-output/soapui/1.0/dev01/UserRestServiceTestSuite-getNewArrivals-getNewArrivals-0-FAILED.txt
       
       
      2 Test Cases Failed in 1.1 Services
      ===========================================
       
      http://ci01.napster.com:8080/hudson/job/API_DEV/ws/NapsterApi/test-output/soapui/1.1/dev01/PurchaseTestSuite-TestPurchaseWithCredits-PurchaseTrackUsingCredits-0-FAILED.txt
      http://ci01.napster.com:8080/hudson/job/API_DEV/ws/NapsterApi/test-output/soapui/1.1/dev01/RadioRestServiceTestSuite-getRadioStationTracksByStationId-getRadioStationTracksByStationId-0-FAILED.txt
    • Continuous Integration
      API QA
      Remote
      API_DEV
      API_QA
      API_AUTO_STAG
      API_AUTO_PROD
    • Another attempt @ mocking SOAP
      ...a little difficult to understand
    • REST
      …RESTeasy 
    • Questions?