└── README.md /README.md: -------------------------------------------------------------------------------- 1 | # API Connect v5 Getting Started: Developer Toolkit Command Line Interface 2 | 3 | [Shane Claussen](mailto:claussen@us.ibm.com), Chief Architect, API Connect 4 | 5 | 6 | 7 | # Introduction 8 | 9 | The API Connect v5 developer toolkit delivers a command line interface 10 | named `apic` to augment the toolset developers use to create and test 11 | APIs to be run, managed, and secured by API Connect. The `apic` 12 | command set also provides capability to support devops oriented 13 | engineering tasks (e.g. continuous integration and delivery). 14 | 15 | To install and use the `apic` CLI you'll need to get a [Bluemix IBM 16 | id](https://bluemix.net), provision [API Connect in 17 | Bluemix (free)](https://new-console.ng.bluemix.net/catalog/services/api-connect), 18 | and then install the [API Connect Developer 19 | Toolkit](https://www.npmjs.com/package/apiconnect). Once installed, type `apic 20 | -h` to see the overall help (after accepting the licensing agreement): 21 | 22 | ``` 23 | $ apic -h 24 | 25 | Usage: apic COMMAND OPTIONS 26 | 27 | Options 28 | -h, --help command usage 29 | -v, --version toolkit version 30 | 31 | Commands (type apic COMMMAND -h for additional help): 32 | 33 | Creating and validating artifacts 34 | config manage configuration variables 35 | create create development artifacts 36 | edit run the API Designer 37 | validate validate development artifacts 38 | 39 | Creating and testing applications 40 | loopback create and manage LoopBack applications 41 | microgateway create Micro Gateway applications 42 | start start services 43 | stop stop services 44 | logs display service logs 45 | props service properties 46 | services service management 47 | 48 | Publishing to the cloud 49 | login log in to an IBM API Connect cloud 50 | logout log out of an IBM API Connect cloud 51 | organizations manage organizations 52 | catalogs manage catalogs in an organization 53 | publish publish products and APIs to a catalog 54 | products manage products in a catalog 55 | apps manage provider applications 56 | drafts manage APIs and products in drafts 57 | ``` 58 | 59 | All the commands use a **command:action** syntax (e.g. `apic 60 | apps:publish`). For the most popular commands, either the command or 61 | action portion is optional to simplify usage. For example: 62 | 63 | - apic auth:login -> apic login 64 | - apic local:create -> apic create 65 | - apic products:publish -> apic publish 66 | - apic products:list -> apic products 67 | 68 | All of the commands take a `-h/--help` option which provides the 69 | command's usage and a handful of useful examples (e.g. `apic publish 70 | -h`). Some of the command usages are annotated with **Stability: 71 | prototype** which indicates we are in the process of collecting 72 | customer feedback on the command and it will likely evolve before it's 73 | certified for production. 74 | 75 | 76 | 77 | # API Designer 78 | 79 | **API Designer** is the graphical design tool provided by the toolkit 80 | to support most of the capablity available via the other command 81 | lines. Use the `apic edit` command to run the API Designer: 82 | 83 | ``` 84 | apic edit 85 | ``` 86 | 87 | Although `apic edit` is likely the most important command in the 88 | toolkit, the intention of this article is to provide an overview of 89 | the entire `apic` command set. That said, if this is your first time 90 | using the toolkit, it's good to know there's a simple graphical 91 | alternative to the CLI. 92 | 93 | 94 | 95 | # APIs and Applications 96 | 97 | The developer toolkit supports development of API proxies and API 98 | implementations. In this article we'll use the term **API** when 99 | we're referring to the API proxy and the term **application** when 100 | we're referring to the API implementation. The developer toolkit 101 | provides a first class integrated development environment for 102 | developing APIs and applications using the [LoopBack 103 | framework](https://docs.strongloop.com/display/APIC/Using+LoopBack+with+IBM+API+Connect). 104 | LoopBack application projects can be created using the loopback 105 | command: 106 | 107 | ``` 108 | apic loopback 109 | ``` 110 | 111 | If you haven't selected an interaction tier framework for developing 112 | APIs and Microservices we suggest you take a hard look at LoopBack 113 | which has a proven track record for enabling interaction tier 114 | applications to be built quickly and easily. However, the developer 115 | toolkit was designed with polyglot in mind. Thus, it can be used to 116 | create APIs in a language independent manner using 117 | [OpenAPI (Swagger)](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md) 118 | to proxy to an existing backend implementation or it can be used to 119 | augment applications developed in other languages/frameworks such as 120 | [Express.JS](http://expressjs.com), Java, 121 | [Swift](https://developer.ibm.com/swift/2016/02/26/video-replay-ibm-announces-new-swift-offerings-tools/), 122 | Go, et al. 123 | 124 | When a developer is using **LoopBack projects**, the toolkit supports 125 | publishing the API to an [**API Connect 126 | Catalog**](https://www.ibm.com/support/knowledgecenter/SSMNED_5.0.0/com.ibm.apic.apionprem.doc/conref_working_with_env.html) 127 | which supports socialization via the developer portal and policy 128 | enforcement via the gateway, and the application to an **API Connect 129 | App** which provides Node.JS runtime capability. 130 | 131 | Developers who want to proxy to existing backend services or who are 132 | developing their applications using other languages or frameworks use 133 | **OpenAPI projects** that support publishing the OpenAPI (Swagger) 134 | definitions to **API Connect Catalogs**. 135 | 136 | 137 | 138 | # Creating Development Artifact Definitions 139 | 140 | Development artifacts (e.g. OpenAPI (Swagger) definitions, API product 141 | definitions, LoopBack models, and LoopBack data sources) can be created using 142 | the `apic create` command. Use the following CLIs to create the different 143 | definition types interactively: 144 | 145 | ``` 146 | apic create --type api 147 | apic create --type product 148 | apic create --type model # Note: Create within a LoopBack application project 149 | apic create --type datasource # Note: Create within a LoopBack application project 150 | ``` 151 | 152 | Product and API definitions can also be created non-interactively by 153 | providing the **--title** option (several values get defaulted from 154 | the title that can be customized with additional options): 155 | 156 | ``` 157 | apic create --type api --title Routes 158 | apic create --type product --title "Climb On" 159 | ``` 160 | 161 | It is also convenient to create the API and product definitions at the 162 | same time: 163 | 164 | ``` 165 | apic create --type api --title Routes --product "Climb On" 166 | ``` 167 | 168 | Alternatively, you can create a couple APIs and then reference them 169 | when you create a new product: 170 | 171 | ``` 172 | apic create --type api --title Routes 173 | apic create --type api --title Ascents 174 | apic create --type product --title "Climb On" --apis "routes.yaml ascents.yaml" 175 | ``` 176 | 177 | 178 | 179 | # Validating Development Artifact Definitions 180 | 181 | 182 | Once you edit the development artifacts or right before you publish the 183 | artifacts it's valuable to validate them: 184 | 185 | ``` 186 | apic validate routes.yaml # Validate an API 187 | apic validate climb-on.yaml # Validate the product and APIs created above 188 | apic validate climb-on.yaml --product-only # Validate the product only (do not validate the referenced APIs) 189 | ``` 190 | 191 | 192 | 193 | # Updating LoopBack Applications 194 | 195 | Once you've created a LoopBack application using `apic loopback` there 196 | are a number of useful commands for updating the application. These 197 | should be run in the application's project directory. Here's an 198 | overview of those commands: 199 | 200 | - **`apic loopback:boot-script`**: Create a new [boot scripts](https://docs.strongloop.com/display/public/APIC/Defining+boot+scripts). 201 | - **`apic loopback:acl`**: Define an [access control list](https://docs.strongloop.com/display/public/APIC/Controlling+data+access) for accessing LoopBack models. 202 | - **`apic loopback:middleware`**: Define and register [Express.JS middleware](https://docs.strongloop.com/display/public/APIC/Defining+middleware) to define the phase of execution. 203 | - **`apic loopback:property`**: Add [additional properties](https://docs.strongloop.com/display/public/APIC/Customizing+models) to a Loopback model. 204 | - **`apic loopback:remote-method`**: Add [remote methods](https://docs.strongloop.com/display/APIC/Using+LoopBack+with+IBM+API+Connect) to a LoopBack model. 205 | - **`apic loopback:relation`**: Add [relationships](https://docs.strongloop.com/display/APIC/Creating+model+relations) between LoopBack models. 206 | - **`apic loopback:export-api-def`**: Export an OpenAPI (Swagger) definition from LoopBack models. 207 | - **`apic loopback:export-api-def`**: Export an OpenAPI (Swagger) and a product definition from LoopBack models. 208 | - **`apic loopback:swagger`**: Generate a LoopBack application from an OpenAPI (Swagger) definition. 209 | 210 | Note: These commands are annotated with **Stability: prototype** 211 | because we are looking for feedback on them before we certify them for 212 | production. 213 | 214 | 215 | 216 | # Managing Services 217 | 218 | The `services` command can be used to manage running processes for 219 | testing APIs and applications. For example, the following commands 220 | can be used to create a LoopBack application project, start the Micro 221 | Gateway and the Node.JS server running the LoopBack application, and 222 | test the API and application using the endpoint exposed by the Micro 223 | Gateway: 224 | 225 | ``` 226 | apic loopback # climbon project name/directory 227 | cd climbon 228 | # update API and/or application development artifacts 229 | apic start 230 | # test the API/application 231 | # update API and/or application development artifacts 232 | # restart the services (result is they run off the latest artifact definitions) 233 | apic start 234 | # test the API/application 235 | apic stop 236 | ``` 237 | 238 | By default, the actions for the `services` command work on the project 239 | or directory relative to where the command was executed enabling 240 | services for multiple projects to be managed concurrently and 241 | independently. 242 | 243 | Here's a sampling of some useful actions for the services command: 244 | 245 | ``` 246 | apic services # list the local running services (alias for services:list) 247 | apic start # start the local services (alias for services:start) 248 | apic stop # stop the local services (alias for services:stop) 249 | apic stop --all # stop all services across all projects 250 | ``` 251 | 252 | While running services and testing APIs and applications it's 253 | typically useful to tail the Micro Gateway and Node.JS LoopBack logs 254 | using the `apic logs` command. Here's a couple examples: 255 | 256 | ``` 257 | apic logs # view the logs for the default service (alias for services:logs) 258 | apic logs --service SERVICE_NAME # use apic services to list the service names 259 | ``` 260 | 261 | The props command provides a mechanism for managing service 262 | properties. Here's a summary of how the props command can be used: 263 | 264 | ``` 265 | apic props # List properties for the default service (alias for props:list) 266 | apic props --service SERVICE_NAME # List properties for the SERVICE_NAME service 267 | apic props:set NAME=VALUE # Set a property on the default service 268 | apic props:get NAME # Get the property for the default service 269 | apic props:delete NAME # Delete the property for the default service 270 | apic props:clear # Clear all the properties on the default service 271 | ``` 272 | 273 | 274 | 275 | # Configuration Variables 276 | 277 | The `apic config` command provides global and project based 278 | configuration variables. These configuration variables will grow over 279 | time, but currently they are used to provide the target catalog and/or 280 | app for publishing APIs and applications. Global configuration is 281 | stored in ~/.apiconnect/config and project/directory level 282 | configuration is stored in PROJECT_DIR/.apiconnect. 283 | 284 | Let's take a look at the catalog and app configuration variables: 285 | 286 | **catalog**: The catalog configuration variable should be set to the 287 | URI of an API Connect catalog. The value of catalog defines a default 288 | catalog target for all commands managing catalogs. The values defined 289 | by the catalog's URI can be overridden using the --server, 290 | --organization, and --catalog command line options. The catalog URI 291 | has the form: 292 | 293 | `apic-catalog://MANAGEMENT_SERVER/orgs/ORGANIZATION_NAME/catalogs/CATALOG_NAME` 294 | 295 | **app**: The app configuration variable should be set to the URI of 296 | API Connect app. The value of app defines the default app target for 297 | all commands managing apps. The values defined by the app's URI can 298 | be overridden using the --server, --organization, and --app command 299 | line options. The app URI has the form: 300 | 301 | `apic-app://MANAGEMENT_SERVER/orgs/ORGANIZATION_NAME/apps/APP_NAME` 302 | 303 | The easiest way to determine the values for these configuration 304 | variables is to sign in to the API Manager application of your 305 | provisioned [Bluemix API Connect 306 | service](https://new-console.ng.bluemix.net/catalog/services/api-connect) 307 | or your on premises cloud, and click on the **link** icon of the 308 | catalog or app you want to publish your API or application to. The 309 | dialog that appears will provide you with the identifier of the 310 | catalog or app along with the appropriate config:set command. 311 | 312 | Although setting these configuration variables is not absolutely 313 | required, they simplify all the command actions that interact with API 314 | Connect clouds by providing default values for the --server, 315 | --organization, --catalog, and --app options. 316 | 317 | Below is an example of using `apic publish` with and without the 318 | catalog configuration variable begin set: 319 | 320 | ``` 321 | # Without 322 | apic publish climb-on.yaml --server mgmnthost.com --organization climbon --catalog sb 323 | 324 | # With 325 | apic config:set catalog=apic-catalog://mgmnthost.com/orgs/climbon/catalogs/sb 326 | apic publish climb-on.yaml 327 | ``` 328 | 329 | A portion of the default values provided by the catalog configuration 330 | variable can also be overridden by explicitly providing one of the 331 | standard options with a different value. For example, the `apic 332 | publish` command can override the catalog portion of the default to 333 | target the Quality Assurance catalog by using the --catalog option: 334 | 335 | ``` 336 | apic publish climb-on.yaml --catalog qa 337 | ``` 338 | 339 | Don't forget about global configuration variables. If you use the 340 | same catalog as the default target for multiple projects set the value 341 | globally: 342 | 343 | ``` 344 | apic config:set --global catalog=apic-catalog://mgmnthost.com/orgs/climbon/catalogs/sb 345 | ``` 346 | 347 | 348 | 349 | # API Connect Cloud Authentication 350 | 351 | The `apic login` and `apic logout` (aliases for auth:login and 352 | auth:logout) commands are used to manage your authentication 353 | credentials for IBM API Connect clouds. Unlike many systems, API 354 | Connect enables you to be simultaneously logged into multiple clouds, 355 | enabling you to easily publish and manage APIs and Applications to 356 | disparate on premises and Bluemix targets. 357 | 358 | Login supports both interactive and non-interactive modes. To login 359 | interactively: 360 | 361 | ``` 362 | $ apic login 363 | Enter your API Connect credentials 364 | ? Server: us.apiconnect.ibmcloud.com 365 | ? Username: claussen@us.ibm.com 366 | ? Password (typing will be hidden) **************** 367 | Logged into us.apiconnect.ibmcloud.com successfully 368 | ``` 369 | 370 | Scripted non-interactive login can be accomplished using the --server, 371 | --username, and --password options. 372 | 373 | 374 | 375 | # Publishing APIs 376 | 377 | Publishing APIs to API catalogs in API Connect clouds enables those 378 | APIs to be socialized via developer portals and secured by gateways. 379 | 380 | API Connect defines the concept of an API product (or product for 381 | short) that's used to compose APIs for publishing. The product 382 | enables API product managers to bundle one or more APIs together, 383 | control the visibility of that product in the developer portal (ie only 384 | allow partners x, y, and z view and subscribe to the product), and 385 | defines one or more plans to provide application developers a set of 386 | consumption options. The products that reference the APIs and define 387 | the consumption plans are also the primary unit of lifecycle 388 | management for APIs. 389 | 390 | The `apic publish` (alias for `apic products:publish`) command is used 391 | to publish API products to an API Connect cloud. The example below 392 | demonstrates creation of a couple APIs composed by a product and how 393 | to publish that product and its APIs to a catalog: 394 | 395 | ``` 396 | apic create --type api --title Routes 397 | apic create --type api --title Ascents 398 | apic create --type product --title "Climb On" --apis "routes.yaml ascents.yaml" 399 | apic config:set catalog=apic-catalog://mgmnthost.com/orgs/climbon/catalogs/sb 400 | apic login --username some-user --password some-password --server mgmnthost.com 401 | apic publish climb-on.yaml 402 | ``` 403 | 404 | The **--stage** option can be tacked onto `apic publish` resulting in 405 | the product being staged into a catalog instead of published (products 406 | have the states of staged, published, deprecated, retired, or archived 407 | in the catalog): 408 | 409 | ``` 410 | apic publish --stage climb-on.yaml 411 | ``` 412 | 413 | 414 | 415 | # Publishing LoopBack APIs and Applications 416 | 417 | LoopBack application projects contain both APIs and applications. The 418 | same `apic publish` command described above is used to publish the 419 | LoopBack APIs and a new command named `apic apps:publish` is used to 420 | publish the LoopBack application. 421 | 422 | When a LoopBack application project is created default API and product 423 | definitions are added to the PROJECT_DIR/definitions directory. 424 | Publishing the API and product artifacts is the same as any other set 425 | of API and product artifacts with the notable difference that these 426 | artifacts can be generated directly from the application's LoopBack 427 | models. Here's a sample CLI narrative for developing and publishing 428 | LoopBack APIs to illustrate that scenario: 429 | 430 | ``` 431 | apic loopback # climbon project name/directory 432 | cd climbon 433 | apic create --type model # as many times as required 434 | apic loopback:property # as many times as required 435 | apic loopback:remote # as many times as required 436 | apic loopback:relation # as many times as required 437 | apic loopback:refresh # (re)generate the product and API artifacts 438 | apic config:set catalog=apic-catalog://mgmnthost.com/orgs/climbon/catalogs/sb 439 | apic login --username some-user --password some-password --server mgmnthost.com 440 | apic publish definitions/climbon-product.yaml 441 | ``` 442 | 443 | In addition to the LoopBack APIs, the LoopBack application itself must 444 | also be published to an API Connect app which represents a Node.JS 445 | runtime. Adding the following two commands to the above set will 446 | result in publishing the LoopBack application (Note: apps:publish must 447 | be run from within the LoopBack application project directory 448 | structure): 449 | 450 | ``` 451 | apic config:set app=apic-app://mgmnthost.com/orgs/climbon/apps/sb-app 452 | apic apps:publish 453 | ``` 454 | 455 | If the LoopBack application is being published to Bluemix, the API 456 | Connect app can optionally be created in the organization on the fly 457 | as a side effect of apps:publish. In that case, the app configuration 458 | variable does not have to be set and the --app option on 459 | `apps:publish` is not required. 460 | 461 | 462 | 463 | # Managing API Products 464 | 465 | The `apic products` and `apic apis` command sets can be used to manage 466 | products and APIs that have been published to API Connect catalogs. 467 | Here's a sample for how the `products` and `apis` commands can be used 468 | for a cradle to grave lifecycle example: 469 | 470 | ``` 471 | apic config:set catalog=apic-catalog://mgmnthost.com/orgs/climbon/catalogs/sb # set the default catalog 472 | apic login --username some-user --password some-password --server mgmnthost.com # login into the mgmnthost.com cloud 473 | apic create --type api --title Routes --product "ClimbOn" # create the product and API 474 | apic publish --stage climbon.yaml # publish the product to staged status 475 | apic products # list the products in the catalog 476 | apic products:get climbon # get the product's properties 477 | apic apis # list the APIs in the catalog 478 | apic apis:get routes # get the API's properties 479 | apic products:set climbon --status published # publish the product (onlines the API) 480 | apic apis:set routes --status offline # take the API offline 481 | apic apis:set routes --status online # bring the API online 482 | apic products:set climbon --status deprecated # deprecate the product 483 | apic products:set climbon --status retired # retire the product 484 | apic products:set climbon --status archived # archive the product 485 | apic products:delete climbon # delete the product from the catalog 486 | ``` 487 | 488 | Here's an example of a more complex lifecycle management scenario 489 | where a new version of a product and API hot replaces the original 490 | version: 491 | 492 | ``` 493 | # Set the default catalog and login to the mgmnthost.com API Connect cloud 494 | apic config:set catalog=apic-catalog://mgmnthost.com/orgs/climbon/catalogs/sb 495 | apic login --username some-user --password some-password --server mgmnthost.com 496 | 497 | # Create and publish an initial version 498 | apic create --type api --title Routes --version 1.0.0 --filename routes100.yaml 499 | apic create --type product --title "Climb On" --version 1.0.0 --apis routes100.yaml --filename climbon100.yaml 500 | apic publish climbon100.yaml 501 | 502 | # Create a new version to fix a bug in the API, stage it to the catalog 503 | apic create --type api --title Routes --version 1.0.1 --filename routes101.yaml 504 | apic create --type product --title "Climb On" --version 1.0.1 --apis routes101.yaml --filename climbon101.yaml 505 | apic publish --stage climbon101.yaml 506 | 507 | # Inspect the catalog 508 | apic products 509 | apic products:get climbon:1.0.0 510 | apic products:get climbon:1.0.1 511 | 512 | # Hot replace version 1.0.0 with 1.0.1 513 | apic products:replace climbon:1.0.0 climbon:1.0.1 --plans default:default 514 | ``` 515 | 516 | In addition to the lifecycle management capabilities, products and 517 | apis in catalogs can be downloaded via the `pull` and `clone` actions: 518 | 519 | ``` 520 | apic products:clone # download all products and their APIs from the catalog 521 | apic products:pull climbon:1.0.0 # download the climbon:1.0.0 product and its APIs from the catalog 522 | apic apis:clone # dwonload all APIs from the catalog 523 | apic apis:pull routes:1.0.0 # download the routes:1.0.0 API from the catalog 524 | ``` 525 | 526 | It's also sometimes useful to clear all products and their APIs from a 527 | catalog particularly for sandbox typed catalogs (this action requires 528 | the name of the catalog as a confirmation parameter): 529 | 530 | ``` 531 | apic products:clear --confirm CATALOG_NAME 532 | ``` 533 | 534 | 535 | 536 | # Drafts 537 | 538 | We encourage developers to co-locate their APIs and applications in 539 | their local source code control systems to support the typical design 540 | time iterative lifecycle activities like commits, branching, merges, 541 | continuous integration, et al. We believe the developer toolkit 542 | provides the bridge from the developer's environment and the API 543 | Connect runtime services. 544 | 545 | That said, API Connect does provide an online development sandbox 546 | capability named **Drafts** where API and product definitions can be 547 | defined. The toolkit provides the `apic drafts` command set to enable 548 | synchronization of product and API artifacts between the developer's 549 | local source code control systems and drafts. 550 | 551 | Similar to the `products` and `apis` command sets, `drafts` can be 552 | used to push, pull, and clone artifacts as follows: 553 | 554 | ``` 555 | apic config:set catalog=apic-catalog://mgmnthost.com/orgs/climbon/catalogs/sb # set the default catalog 556 | apic login --username some-user --password some-password --server mgmnthost.com # login into the mgmnthost.com cloud 557 | 558 | apic create --type api --title routes --product ClimbOn 559 | apic drafts:push climbon.yaml # push climbon:1.0.0 and routes:1.0.0 to drafts 560 | apic drafts # list what is in drafts 561 | apic drafts:get climbon # get climbon:1.0.0 562 | apic drafts:get routes # get routes:1.0.0 563 | apic drafts:pull climbon # pull climbon:1.0.0 and routes:1.0.0 from drafts 564 | apic drafts:clone # pull every product/api from drafts 565 | apic drafts:clear --confirm drafts # clear drafts collection 566 | ``` 567 | 568 | In addition to synchronizing data between the developer's source code 569 | control systems and drafts, products that are in drafts can be 570 | published: 571 | 572 | ``` 573 | apic config:set catalog=apic-catalog://mgmnthost.com/orgs/climbon/catalogs/sb # set the default catalog 574 | apic login --username some-user --password some-password --server mgmnthost.com # login into the mgmnthost.com cloud 575 | 576 | apic create --type api --title routes --product ClimbOn 577 | apic drafts:push climbon.yaml # push climbon:1.0.0 and routes:1.0.0 to drafts 578 | apic drafts:publish climbon 579 | ``` 580 | 581 | Again, although it's possible to develop products and APIs in drafts, 582 | and to use the CLI or the drafts user experience to publish products 583 | from drafts to a catalog, our recommendation is to clone all your 584 | products and apis from drafts, check them into your local source code 585 | control system, and then publish directly from there to your catalogs 586 | using your source code control system, its tags, service branches, et 587 | al, as your master of record. 588 | 589 | 590 | # Summary 591 | 592 | I hope you found the information above on the `apic` command useful! 593 | Feel free to [contact me](emailto:claussen@us.ibm.com) to ask 594 | questions or to provide feedback. 595 | 596 | 597 | 598 | # Additional Resources 599 | 600 | For additional resources pay close attention to the following: 601 | 602 | - [API Connect v5 Getting Started: Developing, Testing, and Publishing an API to Bluemix using `apic`](https://github.com/ibm-apiconnect/climbingweather) 603 | - [API Connect v5 Getting Started: API Products](https://github.com/ibm-apiconnect/product) 604 | - [API Connect Developer Center](https://developer.ibm.com/apiconnect) 605 | - [API Connect v5 Knowledge Center](https://www.ibm.com/support/knowledgecenter/SSMNED_5.0.0/mapfiles/getting_started.html) 606 | - [Follow us @ibmapiconnect](https://twitter.com/ibmapiconnect) 607 | --------------------------------------------------------------------------------