API Best Practices

From MashupCamp

API Best Practices

What should a Mashup API look like? What is the best way to use it? There are 100's of Web APIs, see Programmable Web for many examples. This session will be an open discussion of what makes a good API. We will discuss browser techniques (JSON, Flex for maps, etc.) as well as proxy server techniques (SOAP, REST, etc.). A must attend for API Architects and mashup developers.

List your name if interested (recommended tool or library optional):

• Dave Nielsen, StrikeIron, API Analyzer: A free web tool that displays inputs/outputs of any SOAP-based web service. Just add a WSDL URL.
• Shimmy Mehta, Angelwish.org
• About 20 more in attendance:

===Notes from this session=== (notes provided by Dave Nielsen) Dave opened the session by describing the challenges with several API types, while the group provided further that the group.

• SOAP
  • toolkit support among various languages and platforms is limited. The reason is because most platforms don't handle the SOAP headers and envelope well
  • SOAP Standards are not standardized yet (ex: WSDL)
  • Security isn't standard yet (tho WS*Security & XAML are common)
  • Requires XML, which is not the easiest way to represent data
• REST
  • Lack of Standardization
  • No standardized security
• RSS
  • Structured for Blog posts, not for transactions
  • No standardized security
• ATOM
  • Structured for submitting content, not transactions, tho could be used for some txns
  • No standardized security
• JSON
  • Easy, but no schema with content
  • No standardized security

Security

User data access & security was identified as one of the challenging headaches for Mashup developers. Someone brought up the example of a mashup having to log onto eBay, Yahoo & Google on behalf of the user. Using today's models, the user would have to log into all 3 portals to authorize the mashup. This poses a challenge. Someone suggested we look at OpenID2. Some browser-based security models are:

• Mashup sends user to API Provider (like eBay) where they sign in and redirect user back to mashup, where the mashup receives a token which is good for accessing user data for that session. eBay, Yahoo and Google all use this method.
• Mashup sends user to API Provider (like eBay) where they sign in and redirect user back to mashup, where the mashup receives a token which is good for accessing user data for just that one API call.
• Mashup sends user to API Provider website (like PayPal) where user signs-in and is redirected back to mashup. The mashup receives a token which is good for accessing user data for just that one API call.
• token with proxy lasting for one time