Difference between revisions of "API"

From BC$ MobileTV Wiki
Jump to: navigation, search
(→‎API Keys & Security)
(→‎API Keys & Security)
Line 209: Line 209:
  
 
* REST Security (CHEAT SHEET): https://www.owasp.org/index.php/REST_Security_Cheat_Sheet
 
* REST Security (CHEAT SHEET): https://www.owasp.org/index.php/REST_Security_Cheat_Sheet
−
* Reducing Risk of Credential Compromise @Netflix: https://www.infoq.com/presentations/netflix-infrastructure-security
 
 
<ref>Why API Keys are not enough: https://nordicapis.com/why-api-keys-are-not-enough/</ref>
 
<ref>Why API Keys are not enough: https://nordicapis.com/why-api-keys-are-not-enough/</ref>
 
<ref>Best Practices for Storing / Protecting API Keys : https://developer.oregonstate.edu/faqs/best-practices-storing-protecting-api-keys</ref>
 
<ref>Best Practices for Storing / Protecting API Keys : https://developer.oregonstate.edu/faqs/best-practices-storing-protecting-api-keys</ref>
Line 220: Line 219:
 
<ref>Best practices for securely using API keys: https://support.google.com/googleapi/answer/6310037</ref>
 
<ref>Best practices for securely using API keys: https://support.google.com/googleapi/answer/6310037</ref>
 
<ref>API Key Auth Provider (C#): http://docs.servicestack.net/api-key-authprovider#interoperable</ref>
 
<ref>API Key Auth Provider (C#): http://docs.servicestack.net/api-key-authprovider#interoperable</ref>
 +
<ref>Reducing Risk of Credential Compromise @Netflix: https://www.infoq.com/presentations/netflix-infrastructure-security</ref>
  
 
== Tools ==
 
== Tools ==

Revision as of 18:25, 27 April 2019

An Application Programming Interface (or commonly abbreviated as API), is a mechanism for exposing the core functionality of an application (such as a client or desktop program, web site or web service) to an external application (of any of the previously mentioned types).

Since the days of Web 2.0, an API is seen as a crucial element to any Web Application or Web Service. In general though, APIs are crucial parts of an application design and implementation strategy. They ensure the involvement of third-parties and outside developers in the products and services you create, and they can also help to breed innovation.


Specifications

OpenAPI

Swagger (OpenAPIv2) to OpenAPIv3

OpenAPI is an OSS specification and associated OSS (with commercial/enterprise-grade supported options) set of tools for Designing, Documenting, Sharing, Inspecting/Analyzing, Stubbing/Mocking, Validating, Comparing and/or Serving API endpoints and their associated Auth mechanisms, Headers, request/response pair examples, actual payloads, error messsages/conditions around, etc. It is seen as the cross-platform (SOAP, REST, REST-JSON/XML, XML-RPC, etc) Web Service documentation alternative to the more protocol-specific WSDL (SOAP) & WADL (REST) specifications.

For more, see: OpenAPI

[2] [3] [4] [5] [6] [7] [8] [9] [10] [11]

RAML

Rest API Markup Language (RAML) is Mulesoft's alternative to Swagger/OpenAPI.

APIs.json

APIs.json is a machine readable approach that API providers can use to describe their API operations, similar to how web sites are described using the Sitemap.xml spec but for listing/discovery of Web Services and their operations.

[13]



Types of APIs

Native/Library

A Native or Library API is typically an operating system-specific or programming language-specific one which provides access to certain data, methods/functionality, or commonly required utilities.

Web Services

Web Services are remotely callable functionality residing in another application.

XML-RPC

XML-RPC was one of the first examples of a Web Service format for remotely exchanging data, specifying the format as a strict set of XML "methods" and.

RequestResponse
 <?xml version="1.0" encoding="utf-8"?>
 <methodCall>
    <methodName>myService.sum</methodName>
    <params>
       <param>
          <value><int>17</int></value>
       </param>	 
       <param>
          <value><int>13</int></value>
       </param>
    </params>
 </methodCall>

 <methodResponse>
    <params>
       <param>
          <value><int>30</int></value>
       </param>
    </params>
 </methodResponse>


SOAP

SOAP is a contract-based (contract-first or contract-last, but contract nonetheless) approach to cross-application communication.

RequestResponse

GET http://www.mysite.com/myService?wsdl

--> Lookup required Web Service "operation"

POST http://www.mysite.com/getAddition 

 <?xml version="1.0" encoding="utf-8"A?>
 <soap:Envelope
    xmlns:soap="http://www.w3.org/2003/05/soap-envelope/"
    soap:encodingStyle="http://www.w3.org/2003/05/soap-encoding">
   <soap:Header>
      <To xmlns="http://www.w3.org/2005/08/addressing">http://www.mysite.com:8181/Math/</To>
      <Action xmlns="http://www.w3.org/2005/08/addressing">tns:getAdditon_Request</Action>
      <ReplyTo xmlns="http://www.w3.org/2005/08/addressing">
         <Address>http://www.w3.org/2005/08/addressing/anonymous</Address>
      </ReplyTo>
   </soap:Header>
   <soap:Body>
   <Math:getAddition>
      <Math:number1>17</Math:number1>
      <Math:number2>13</Math:number2>
   </Math:getAddition>
   </soap:Body>
 </soap:Envelope> 

 <?xml version="1.0" encoding="utf-8"A?>
 <soap:Envelope
    xmlns:soap="http://www.w3.org/2003/05/soap-envelope/"
    soap:encodingStyle="http://www.w3.org/2003/05/soap-encoding">
   <soap:Header>
       <ResponseHeader xmlns="https://www.mysite.com/apis/Math/v2017-08-17">
         <requestId>123456789</requestId>
         <responseTime>1350</responseTime>
       </ResponseHeader>
   </soap:Header>
   <soap:Body>
     <Math:getAddition>
        <Math:value>30</Math:value>
     </Math:getAddition>
   </soap:Body>
 </soap:Envelope>
  • For more, see section: SOAP

REST

REST is a direct access-based approach to cross-application communication, where the API's documentation is typically relied upon heavily to describe how to access it. When REST is done properly though, using a RESTful approach, the API becomes mostly self-documenting, instead relying on the Create-Read-Update-Delete (CRUD) to HTTP POST-GET-PUT-DELETE relationship to describe how to access the Web Service and interact with its data.

RequestResponse
GET http://www.mysite.com/myService?number=17&number2=13 
 {
   "value" : "30"
 }

Although, in reality a REST endpoint can be as complex or simplistic to call as you want, to be truly "RESTful" it should follow certain conventions. The simplistic example above of passing two numbers as input parameters would likely be highly criticized by RESTful WS purist, perhaps to look more like this: 

GET http://www.mysite.com/add/{input1}/{input2}

Others still may argue that since it is "changing a resource" (i.e. doing addition with the two inputs its given) it should be a POST request without any parameters or additional paths beyond and the inputs should be passed in the HTTP message body: 

POST http://www.mysite.com/add
BODY input1=17&input2=13

There is no right or wrong answer, only opinion, as the REST approach is far less structured/defined and more open to interpretation.

  • For more, see section: REST

[14]


API Design

5 essentials for a great API

  1. Provide a valuable service
  2. Have a plan and a business model
  3. Make it simple and flexible
  4. It should be managed and measured
  5. Provide great developer support (Docs, API Console, Example Client Implementations/SDKs, Sandbox)[15]

API Keys & Security

[16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26]

Tools


API Management

[39]

SoapUI

See: SoapUI


Resources

JavaScript

JavaScript APIs (sometimes called JSON APIs or JSONp APIs) require only a standard <script> tag to be added to a webpage in order to expose their functionality. For example: 

 <script type="text/javascript" src="http://www.somesite.com/somejavascript.js"></script>

would expose the functionalities of the somejavascript API that belongs to somesite.com

Java

Java has strong support for intra-application and inter-application integration and interaction via making publically callable methods so that other programs can reuse application logic and methods.

C

The most widespread APIs in use today though, are probably the C APIs available for Unix and ported to other systems. These make it possible to do a number of complex tasks using a much smaller amount of code than if every set of logic had to be programmed manually.


Tutorials

External Links

References

  1. ↑ What is OpenAPI?: https://swagger.io/docs/specification/about/
  2. ↑ The OpenAPI Specification Version 3.0 Highlights: https://apievangelist.com/2017/01/25/the-openapi-specification-version-30-highlights/
  3. ↑ Open API Initiative Announces Release of the OpenAPI Spec v3 Implementer’s Draft: https://www.openapis.org/blog/2017/03/01/openapi-spec-3-implementers-draft-released
  4. ↑ OpenAPI 3.0, And What It Means for the Future of Swagger (WEBINAR): https://swaggerhub.com/blog/api-resources/openapi-3-0-video-tutorial/ | SLIDES
  5. ↑ A Visual Guide to What's New in Swagger 3.0: https://blog.readme.io/an-example-filled-guide-to-swagger-3-2/
  6. ↑ Comparing OpenAPI/Swagger 2.0 and 3.0.0-rc1: https://dev.to/mikeralphson/comparing-openapiswagger-20-and-300-rc1
  7. ↑ What’s New in OpenAPI 3.0: http://nordicapis.com/whats-new-in-openapi-3-0/
  8. ↑ Looking to Create OpenAPI 3.0 For Your API? Swagger Inspector Has Your Back: https://swagger.io/blog/convert-oas-3-swagger-inspector/#sendgrid_mc_email_subscribe
  9. ↑ Migrating to OpenAPI 3.0 -- How to Convert Your Existing APIs with Swagger Tools: https://swagger.io/resources/webinars/convert-api-to-oas-3-with-swagger-tools/
  10. ↑ Tutorial - Converting your Swagger 2.0 API Definition to OpenAPI 3.0: https://blog.runscope.com/posts/tutorial-upgrading-swagger-2-api-definition-to-openapi-3
  11. ↑ Collaborating Across the API Lifecycle -- How to Setup an API Workflow that Scales: https://swagger.io/resources/webinars/collaborating-across-the-api-lifecycle/
  12. ↑ wikipedia: RAML (software)
  13. ↑ API Discovery Is for Internal or External Services: https://dzone.com/articles/api-discovery-is-for-internal-or-external-services
  14. ↑ The Star Wars API (SWAPI): https://swapi.co
  15. ↑ Is the API Landscape Broken?: http://www.wired.com/insights/2013/01/is-the-api-landscape-broken/
  16. ↑ Why API Keys are not enough: https://nordicapis.com/why-api-keys-are-not-enough/
  17. ↑ Best Practices for Storing / Protecting API Keys : https://developer.oregonstate.edu/faqs/best-practices-storing-protecting-api-keys
  18. ↑ Google Developers - API Key Best Practices: https://developers.google.com/maps/api-key-best-practices
  19. ↑ Google Developers - Guide to Using API Keys: https://cloud.google.com/docs/authentication/api-keys?hl=en&visit_id=636795263018130436-4272006704&rd=1
  20. ↑ Client-Side Storage options with HTML5: https://www.html5rocks.com/en/tutorials/offline/storage/
  21. ↑ Best Practices for Designing a Pragmatic RESTful API: https://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api
  22. ↑ Best practices for building secure API Keys: https://medium.freecodecamp.org/best-practices-for-building-api-keys-97c26eabfea9
  23. ↑ Best practices for securely storing API keys: https://medium.freecodecamp.org/how-to-securely-store-api-keys-4ff3ea19ebda
  24. ↑ Best practices for securely using API keys: https://support.google.com/googleapi/answer/6310037
  25. ↑ API Key Auth Provider (C#): http://docs.servicestack.net/api-key-authprovider#interoperable
  26. ↑ Reducing Risk of Credential Compromise @Netflix: https://www.infoq.com/presentations/netflix-infrastructure-security
  27. ↑ How to Use Postman to Manage and Execute Your APIs: http://dzone.com/articles/how-to-use-postman-to-manage-and-execute-your-apis
  28. ↑ Cisco DevNet uses Postman to grow their developer community: http://blog.getpostman.com/2018/05/18/cisco-devnet-uses-postman-to-grow-their-developer-community/
  29. ↑ Rapido - A Sketching Tool for Web API Designers (WHITEPAPER): http://www.www2015.it/documents/proceedings/companion/p1509.pdf
  30. ↑ Sketching Web APIs: http://www.slideshare.net/ronniemitra/sketching-web-apis
  31. ↑ wikipedia: Burp suite
  32. ↑ BestBuy API - Getting Started guide: https://developer.bestbuy.com/documentation/getting-started
  33. ↑ Best Buy API - NodeJS SDK: http://github.com/BestBuyAPIs/bestbuy-sdk-js
  34. ↑ Former BestBuy BBYopen - Developer API console: http://web.archive.org/web/20130309114440/https://bbyopen.com/developer-tools/api-console
  35. ↑ Amazon Dev Tools - Signed Request Helper: https://aws.amazon.com/developertools/351
  36. ↑ Source Code for Brightcove API test tool: https://github.com/BrightcoveOS/API-Test-Tool
  37. ↑ Introducing Mashery: http://mashery.mashery.com/docs/Provider
  38. ↑ How Apiary works: https://apiary.io/how-it-works
  39. ↑ 10 Ways API Management Improves Product Development:: https://www.mulesoft.com/sites/default/files/resource-assets/10%20Ways%20API%20Management%20Improves%20Product%20Development.pdf
  40. ↑ Announcing Mule API Hub: http://blogs.mulesoft.com/dev/api-dev/introducing-apihub/
  41. ↑ Design patterns for Microservices: https://dzone.com/articles/design-patterns-for-microservices
  42. ↑ API Management of comparative views of "real-world" design: https://dzone.com/guides/api-management-comparative-views-of-real-world-des
  43. ↑ Securing a REST Service: https://dzone.com/articles/securing-a-rest-service
  44. ↑ Swagger Generation With Spring Boot: https://dzone.com/articles/swagger-generation-with-spring-boot
  45. ↑ Versioning RESTful Services With Spring Boot: https://dzone.com/articles/versioning-restful-services-with-spring-boot

See Also

Web Services | ESB

Retrieved from "http://wiki.bcmoney-mobiletv.com/index.php?title=API&oldid=50008"