This is the second in a series of articles on the six sections of Cisco’s DevNet Associate Exam DEVASC 200-901, which leads to the Cisco Certified DevNet Associate certification.
Welcome to the second of the series of six articles where I will break down the blueprint sections for the DEVASC 200-901 exam. There are six major topic areas in this 120 minute exam.
If you use technology then you’re already using APIs. This section will explore how APIs make everything in IT programmable. This section is worth 20% of the exam because understanding APIs is foundational for developing automation, so let’s chop it up!
2.1 Construct a REST API request to accomplish a task given API documentation
2.2 Describe common usage patterns related to webhooks
2.3 Identify the constraints when consuming APIs
2.4 Explain common HTTP response codes associated with REST APIs
2.5 Troubleshoot a problem given the HTTP response code, request and API documentation
2.6 Identify the parts of an HTTP response (response code, headers, body)
2.7 Utilize common API authentication mechanisms: basic, custom token, and API keys
2.8 Compare common API styles (REST, RPC, synchronous, and asynchronous)
2.9 Construct a Python script that calls a REST API using the requests library
REST API
In order to be successful on this exam, you must know the basics of APIs. An Application Programming Interface (API) is a way for two pieces of software to talk to each other. Representational State Transfer (REST) is an architecture style for designing networked applications. REST is centered around the HTTP request and response model. Consuming an API is just as simple as making an HTTP request and receiving a response in the payload. With REST we can also program devices. In both cases we need to understand the taxonomy of a REST URL “API Call” and apply the available methods for “CRUD” Create, Read, Update, and Delete. Suffice it to say, for this exam you must know when and how to use GET, POST, PUT, PATCH, and DELETE actions.
Hmmm, did we get ahead of ourselves? Yup, before we can CRUD, we must authenticate. REST API is more of a style than a strict standard, consequently your devices may vary on authentication methods required in the HTTPs header. Make sure you understand the differences between basic, custom token, and API keys.
Basic REST API Request
Webhooks
Webhooks are one way that apps can send automated messages or information to other apps. The benefit of using webhooks is that they allow your application to receive real-time data. Webhooks work well for application integrations and bots.
Looking at Cisco Webex Teams as an example, you can use webhooks to keep up with the state of your resources (i.e. rooms, messages, memberships, etc.). For instance, let’s say you want to be notified when someone posts a message in a chat room that you’re interested in. You can create a webhook to have Webex Teams notify you whenever new messages are posted into that room. So, instead of your app having to make repeated calls to the API to determine if a new message has been posted into the room, the webhook will automatically notify you of their occurrence.
Basic Webex Teams Bot with Webhook
Trouble Shooting
Thus far we’ve discussed the anatomy and benefits of interacting directly or between applications with APIs. Let’s now examine how to validate success or failures using REST API response codes. Some of the REST API response errors are absolute. Some requests can be retried immediately to get a successful response. Some responses require more information from HTTP headers or body of the response.
Example Good Responses
- 200 OK
- Standard response for successful HTTP requests.
- 201 Created
- The request has been fulfilled, resulting in the creation of a new resource.[9]
- 202 Accepted
- The request has been accepted for processing, but the processing has not been completed.
- 206 Partial Content
- The server is delivering only part of the resource because of a range header
Redirect Examples
- 301 Moved Permanently
- This and all future requests should be directed to the given URI
- 303 See Other
- The response to the request can be found under another URI using the GET method.
- 304 Not Modified
- 307 Temporary Redirect
- In this case, the request should be repeated with another URI; however, future requests should still use the original URI. In contrast to how 302 was historically implemented, the request method is not allowed to be changed when reissuing the original request. For example, a POST request should be repeated using another POST request.
- 308 Permanent Redirect
- The request and all future requests should be repeated using another URI. 307 and 308 parallel the behaviors of 302 and 301, but do not allow the HTTP method to change. So, for example, submitting a form to a permanently redirected resource may continue smoothly.
Failed Requests examples
- 400 Bad Request
- You did not send a valid request and remote side is refusing to process further.
- 401 Unauthorized:You need to use some form of authentication like an API key, API token, or username and password pair.
- 403 Forbidden:You do not have the permission to access the resource, even if you are authenticated and authorized.
- 429 Too Many Requests
Server Issues
- 500 Internal Server Error
- A generic error message, given when an unexpected condition was encountered and no more specific message is suitable.
- 501 Not Implemented
- The server does not recognize the request method.
- 502 Bad Gateway
- The server was acting as a gateway or proxy and received an invalid response from the upstream server.
- 503 Service Unavailable
- The server cannot handle the request (because it is overloaded or down for maintenance).
- 504 Gateway Timeout
- The server was acting as a gateway or proxy and did not receive a timely response from the upstream server.
Remember, these APIs topics are also covered in the DEVASC Developing Applications and Automating Workflows Using Cisco Core Platforms class. Thank you for reviewing this summary breakdown of the API section of the DevNet Associate blueprint. Hopefully it contributes towards your success.
Training Resources:
DevNet Certifications
DevNet Training
DevNet CDL XL
Cisco Training
Read the other articles from this series:
Section 1: Software Development and Design
