API

From BC$ MobileTV Wiki
Revision as of 12:16, 3 March 2022 by Bcmoney (Talk | contribs) (API Security Testing)

Jump to: navigation, search

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] [12]


AsyncAPI

Event Driven Architecture (EDA) focused API specification format that supports special documentation for push, WebHooks, messaging, long-polling, etc...


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]


RAML

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


WADL

Web Application Description Language (WADL).

For more, see: WADL


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


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

[17] [18] [19]

[20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40]

API Security Testing

[41] [42] [43] [44] [45] [46] [47] [48] [49]

Tools


API Management

[63]

SoapUI

See: SoapUI

ServiceV

See: ServiceV


Postman

[64]

Resources

[66] [67] [68] [69] [70] [71]

EXAMPLES


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. How about OpenAPI descriptions and Swagger UI in your Java REST API?: https://tryingthings.wordpress.com/2020/05/20/how-about-openapi-descriptions-and-swagger-ui-in-your-java-rest-api/
  13. API Discovery Is for Internal or External Services: https://dzone.com/articles/api-discovery-is-for-internal-or-external-services
  14. wikipedia: RAML (software)
  15. Is the API Landscape Broken?: http://www.wired.com/insights/2013/01/is-the-api-landscape-broken/
  16. Demystifying the "OWASP API security top 10": https://media.bitpipe.com/io_15x/io_157878/item_2411117/cqnc-ebook-owasp.pdf
  17. Predicting the Next OWASP API Security Top 10: https://threatpost.com/owasp-api-security-top-10/175961/
  18. The 2021 Guide to API Security -- What You Need to Know: https://appsecengineer.com/hackerman-hub/2021-guide-api-security-what-you-need-know
  19. The state of API Security 2022 - global research comparison: https://www.cybersprint.com/blog/the-state-of-api-security-global-research-comparison
  20. Awesome API Security: https://github.com/arainho/awesome-api-security
  21. Collection of awesome API Security tools & resources: https://reconshell.com/api-security/
  22. API Sprawl a Looming Threat to Digital Economy: https://devops.com/api-sprawl-a-looming-threat-to-digital-economy/
  23. Benefits of Adopting Zero Trust for API Security: https://www.cm-alliance.com/cybersecurity-blog/benefits-of-adopting-zero-trust-for-api-security
  24. HTTP request smuggling: https://portswigger.net/web-security/request-smuggling
  25. Why API Keys are not enough: https://nordicapis.com/why-api-keys-are-not-enough/
  26. Best Practices for Storing / Protecting API Keys: https://developer.oregonstate.edu/faqs/best-practices-storing-protecting-api-keys
  27. Google Developers - API Key Best Practices: https://developers.google.com/maps/api-key-best-practices
  28. Google Developers - Guide to Using API Keys: https://cloud.google.com/docs/authentication/api-keys?hl=en&visit_id=636795263018130436-4272006704&rd=1
  29. Client-Side Storage options with HTML5: https://www.html5rocks.com/en/tutorials/offline/storage/
  30. Best Practices for Designing a Pragmatic RESTful API: https://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api
  31. Best practices for building secure API Keys: https://medium.freecodecamp.org/best-practices-for-building-api-keys-97c26eabfea9
  32. Best practices for securely storing API keys: https://medium.freecodecamp.org/how-to-securely-store-api-keys-4ff3ea19ebda
  33. Best practices for securely using API keys: https://support.google.com/googleapi/answer/6310037
  34. API Key Auth Provider (C#): http://docs.servicestack.net/api-key-authprovider#interoperable
  35. Reducing Risk of Credential Compromise @Netflix: https://www.infoq.com/presentations/netflix-infrastructure-security
  36. API Security -- Deep Dive into OAuth and OpenID Connect: https://nordicapis.com/api-security-oauth-openid-connect-depth/
  37. API Security -- The 4 Defenses of The API Stronghold: https://nordicapis.com/api-security-the-4-defenses-of-the-api-stronghold/
  38. Equipping Your API With The Right Armor: https://nordicapis.com/api-security-equipping-your-api-with-the-right-armor/
  39. Techniques and Technologies to Increase API Security: https://nordicapis.com/building-a-secure-api/
  40. Application Security Tools Are Not up to the Job of API Security: https://thenewstack.io/application-security-tools-are-not-up-to-the-job-of-api-security/
  41. Introducing vAPI – an open source lab environment to learn about API security: https://portswigger.net/daily-swig/introducing-vapi-an-open-source-lab-environment-to-learn-about-api-security
  42. Go Fuzz Yourself – How to Find More Vulnerabilities in APIs Through Fuzzing: https://labs.detectify.com/2021/08/31/go-fuzz-yourself-how-to-find-more-vulnerabilities-in-apis-through-fuzzing-whitepaper-download/
  43. Save API Costs With "Data-Centric Security": https://hackernoon.com/save-api-costs-with-data-centric-security
  44. More Simple = Less API Attack Vectors: https://securityboulevard.com/2022/01/more-simple-less-api-attack-vectors/
  45. OWASP Juice Shop: https://owasp.org/www-project-juice-shop/
  46. How to Simplify Your API to Narrow Attack Vectors: https://www.threatx.com/blog/api-attack-vectors-how-to-narrow-reduce/
  47. Intercepting HTTPS traffic with Burp Suite: https://resources.infosecinstitute.com/topic/intercepting-https-traffic-with-burp-suite/
  48. API Security Testing With Postman and OWASP Zap: https://thetesttherapist.com/2022/02/13/api-security-testing-with-postman-and-owasp-zap/
  49. Hacking and reviewing Elgato Key Light API with Postman: https://apihandyman.io/hacking-elgato-key-light-with-postman/
  50. How to Use Postman to Manage and Execute Your APIs: http://dzone.com/articles/how-to-use-postman-to-manage-and-execute-your-apis
  51. 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/
  52. Rapido - A Sketching Tool for Web API Designers (WHITEPAPER): http://www.www2015.it/documents/proceedings/companion/p1509.pdf
  53. Sketching Web APIs: http://www.slideshare.net/ronniemitra/sketching-web-apis
  54. wikipedia: Burp suite
  55. AuthMatrix extension v0.8.1 for BurpSuite: https://github.com/SecurityInnovation/AuthMatrix
  56. BestBuy API - Getting Started guide: https://developer.bestbuy.com/documentation/getting-started
  57. Best Buy API - NodeJS SDK: http://github.com/BestBuyAPIs/bestbuy-sdk-js
  58. Former BestBuy BBYopen - Developer API console: http://web.archive.org/web/20130309114440/https://bbyopen.com/developer-tools/api-console
  59. Amazon Dev Tools - Signed Request Helper: https://aws.amazon.com/developertools/351
  60. Source Code for Brightcove API test tool: https://github.com/BrightcoveOS/API-Test-Tool
  61. Introducing Mashery: http://mashery.mashery.com/docs/Provider
  62. How Apiary works: https://apiary.io/how-it-works
  63. 10 Ways API Management Improves Product Development:: https://www.mulesoft.com/sites/default/files/resource-assets/10%20Ways%20API%20Management%20Improves%20Product%20Development.pdf
  64. Postman Collection for Salesforce - Mock Servers & Code Snippets: https://dzone.com/articles/postman-collection-for-salesforce-mock-servers-and
  65. Announcing Mule API Hub: http://blogs.mulesoft.com/dev/api-dev/introducing-apihub/
  66. API Tokens -- A Tedious Survey: https://fly.io/blog/api-tokens-a-tedious-survey/
  67. Checklist for API Verification: https://dzone.com/articles/checklist-for-api-verification
  68. 10 API security guidelines and best practices: https://searchapparchitecture.techtarget.com/tip/10-API-security-guidelines-and-best-practices
  69. Using APIs With PHP? Here Are Your Classes: http://jeez.eu/2009/11/23/using-apis-with-php-here-are-your-classes/
  70. Developer Experience (BLOG): https://web.archive.org/web/20180831161730/http://developerexperience.org/day/2012/05/01
  71. Two Breeds of API -- API Products .vs. API Solutions: http://api-as-a-product.com/articles/digital-transformation-api-product/
  72. Design patterns for Microservices: https://dzone.com/articles/design-patterns-for-microservices
  73. API Management of comparative views of "real-world" design: https://dzone.com/guides/api-management-comparative-views-of-real-world-des
  74. Securing a REST Service: https://dzone.com/articles/securing-a-rest-service
  75. Swagger Generation With Spring Boot: https://dzone.com/articles/swagger-generation-with-spring-boot
  76. Versioning RESTful Services With Spring Boot: https://dzone.com/articles/versioning-restful-services-with-spring-boot
  77. Ffuf - A fast web fuzzer written in Go: https://hakin9.org/ffuf-a-fast-web-fuzzer-written-in-go/
  78. FFUF (Fuzz Faster U Fool) – An Open Source Fast Web Fuzzing ToolAttribution link: https://latesthackingnews.com/2019/12/08/ffuf-fuzz-faster-u-fool-an-open-source-fast-web-fuzzing-tool

See Also

Web Services | ESB | Microservices | API Gateway | Discovery | Security