Difference between revisions of "API"

From BC$ MobileTV Wiki
Jump to: navigation, search
Line 69: Line 69:
'''W'''eb '''A'''pplication '''D'''escription '''L'''anguage (''WADL'').
'''W'''eb '''A'''pplication '''D'''escription '''L'''anguage (''WADL'').
* [[wikipedia: WADL]]
* For more, see: [[WADL]]

Revision as of 11:24, 17 September 2021

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.



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]


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.



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


Web Application Description Language (WADL).

  • For more, see: WADL

Types of APIs


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 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.

 <?xml version="1.0" encoding="utf-8"?>


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


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?>
      <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">
 <?xml version="1.0" encoding="utf-8"A?>
       <ResponseHeader xmlns="https://www.mysite.com/apis/Math/v2017-08-17">
  • For more, see section: SOAP


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.

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

[16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30]

API Security Testing

[31] [32]


API Management



See: SoapUI


See: ServiceV


[48] [49] [50] [51] [52]



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 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.


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.


External Links


  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. 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. API Security -- Deep Dive into OAuth and OpenID Connect: https://nordicapis.com/api-security-oauth-openid-connect-depth/
  28. API Security -- The 4 Defenses of The API Stronghold: https://nordicapis.com/api-security-the-4-defenses-of-the-api-stronghold/
  29. Equipping Your API With The Right Armor: https://nordicapis.com/api-security-equipping-your-api-with-the-right-armor/
  30. Techniques and Technologies to Increase API Security: https://nordicapis.com/building-a-secure-api/
  31. 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/?utm_source=referral&utm_medium=referral&utm_campaign=alissaknight
  32. Save API Costs With "Data-Centric Security": https://hackernoon.com/save-api-costs-with-data-centric-security
  33. How to Use Postman to Manage and Execute Your APIs: http://dzone.com/articles/how-to-use-postman-to-manage-and-execute-your-apis
  34. 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/
  35. Rapido - A Sketching Tool for Web API Designers (WHITEPAPER): http://www.www2015.it/documents/proceedings/companion/p1509.pdf
  36. Sketching Web APIs: http://www.slideshare.net/ronniemitra/sketching-web-apis
  37. wikipedia: Burp suite
  38. AuthMatrix extension v0.8.1 for BurpSuite: https://github.com/SecurityInnovation/AuthMatrix
  39. BestBuy API - Getting Started guide: https://developer.bestbuy.com/documentation/getting-started
  40. Best Buy API - NodeJS SDK: http://github.com/BestBuyAPIs/bestbuy-sdk-js
  41. Former BestBuy BBYopen - Developer API console: http://web.archive.org/web/20130309114440/https://bbyopen.com/developer-tools/api-console
  42. Amazon Dev Tools - Signed Request Helper: https://aws.amazon.com/developertools/351
  43. Source Code for Brightcove API test tool: https://github.com/BrightcoveOS/API-Test-Tool
  44. Introducing Mashery: http://mashery.mashery.com/docs/Provider
  45. How Apiary works: https://apiary.io/how-it-works
  46. 10 Ways API Management Improves Product Development:: https://www.mulesoft.com/sites/default/files/resource-assets/10%20Ways%20API%20Management%20Improves%20Product%20Development.pdf
  47. Announcing Mule API Hub: http://blogs.mulesoft.com/dev/api-dev/introducing-apihub/
  48. API Tokens -- A Tedious Survey: https://fly.io/blog/api-tokens-a-tedious-survey/
  49. 10 API security guidelines and best practices: https://searchapparchitecture.techtarget.com/tip/10-API-security-guidelines-and-best-practices
  50. Using APIs With PHP? Here Are Your Classes: http://jeez.eu/2009/11/23/using-apis-with-php-here-are-your-classes/
  51. Developer Experience (BLOG): https://web.archive.org/web/20180831161730/http://developerexperience.org/day/2012/05/01
  52. Two Breeds of API -- API Products .vs. API Solutions: http://api-as-a-product.com/articles/digital-transformation-api-product/
  53. Design patterns for Microservices: https://dzone.com/articles/design-patterns-for-microservices
  54. API Management of comparative views of "real-world" design: https://dzone.com/guides/api-management-comparative-views-of-real-world-des
  55. Securing a REST Service: https://dzone.com/articles/securing-a-rest-service
  56. Swagger Generation With Spring Boot: https://dzone.com/articles/swagger-generation-with-spring-boot
  57. Versioning RESTful Services With Spring Boot: https://dzone.com/articles/versioning-restful-services-with-spring-boot
  58. Ffuf - A fast web fuzzer written in Go: https://hakin9.org/ffuf-a-fast-web-fuzzer-written-in-go/
  59. 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