# Summary

In this chapter, we focused primarily on what some of the "best practices" are when designing a RESTful API.

We explored what it meant to properly design the URI portion by following a set of styling, pathing, and optional query guidelines.

We also took a look at the different method verbs such as GET, POST, DELETE; the characteristics of what each of them contain and when to use them.

On top of that, we took a peak into the most used response codes and when to properly use them in order effectively communicate with our clients and consumers.

We then moved on to designing the response of our service and how we should implement consistency and safety in our representational output to the client.

Then, we moved on to metadata and looked at the some of the most common used headers related to content, caching, and media types.

Next, we saw how to version our API and what different types of strategies to employ to ensure that our RESTful service can withstand the test of time.

Moving forward, we dove deep into the security aspect of our API and what are the most common security vulnerabilities we should be aware of.

After that, we saw different types of documentation styles and how even a simple concept like documentation has official specifications that we can follow.

Lastly, we put together all that we've learned in this chapter and examined how GitHub as a company has applied these very simple guidelines into their API over years.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://book.restfulnode.com/part-2/chapter-3/summary.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
