{"id":17476898,"url":"https://github.com/merodriguezblanco/rest-api-style-guide","last_synced_at":"2026-02-09T22:04:46.026Z","repository":{"id":146576562,"uuid":"107198322","full_name":"merodriguezblanco/rest-api-style-guide","owner":"merodriguezblanco","description":"Rest API Style Guide","archived":false,"fork":false,"pushed_at":"2020-06-22T16:43:51.000Z","size":29,"stargazers_count":3,"open_issues_count":0,"forks_count":0,"subscribers_count":2,"default_branch":"master","last_synced_at":"2025-08-19T05:42:13.196Z","etag":null,"topics":["api","rest","rest-api","style-guide","styleguide"],"latest_commit_sha":null,"homepage":"","language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/merodriguezblanco.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":"CONTRIBUTING.md","funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2017-10-17T00:37:07.000Z","updated_at":"2024-12-16T12:05:06.000Z","dependencies_parsed_at":null,"dependency_job_id":"f15e9187-d9e1-4b33-9c6f-2b52b7c6b785","html_url":"https://github.com/merodriguezblanco/rest-api-style-guide","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/merodriguezblanco/rest-api-style-guide","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/merodriguezblanco%2Frest-api-style-guide","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/merodriguezblanco%2Frest-api-style-guide/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/merodriguezblanco%2Frest-api-style-guide/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/merodriguezblanco%2Frest-api-style-guide/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/merodriguezblanco","download_url":"https://codeload.github.com/merodriguezblanco/rest-api-style-guide/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/merodriguezblanco%2Frest-api-style-guide/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":29283033,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-02-09T21:57:15.303Z","status":"ssl_error","status_checked_at":"2026-02-09T21:57:11.537Z","response_time":56,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.6:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["api","rest","rest-api","style-guide","styleguide"],"created_at":"2024-10-18T19:43:02.378Z","updated_at":"2026-02-09T22:04:46.007Z","avatar_url":"https://github.com/merodriguezblanco.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"# REST API Style Guide\n\n## Overview\nThis document is intended to provide guidelines and examples used across the partition of a big monolithic app into separate micro-services using [REST](http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm).\n\nThe concepts explained here are not tied to any technology or framework in particular (rails, JS, C#, etc) and are the result of our learnings while working on this awesome project.\n\nWe hope this document is of interest and useful to API designers.\n\nThis document borrows concepts and guidelines heavily from:\n* [RESTful Web Services](http://www.amazon.com/RESTful-Web-Services-Leonard-Richardson/dp/0596529260)\n* [REST API Design Rulebook](https://www.amazon.com/REST-Design-Rulebook-Mark-Masse/dp/1449310508/ref=sr_1_1?ie=UTF8\u0026qid=1508110170\u0026sr=8-1\u0026keywords=rest+api+design+rulebook)\n* [Restful Web Services Cookboox](http://www.amazon.com/RESTful-Web-Services-Cookbook-Scalability/dp/0596801688)\n* [Heroku API Style Guide](https://github.com/interagent/http-api-design)\n* [Service-Oriented Design with Ruby and Rails](http://www.amazon.com/Service-Oriented-Design-Addison-Wesley-Professional-Series/dp/0321659368)\n\n## Contributions\nAPI design is a team sport. We welcome [contributions](CONTRIBUTING.md).\n\n## Contents\n- [Introduction](#introduction)\n  - [REST](#rest)\n  - [REST APIs](#rest-apis)\n- [Identifying REST Resources](#identifying-rest-resources)\n  - [Resource Types](#resource-types)\n    - [Singleton resource](#singleton-resource)\n    - [Collection resource](#collection-resource)\n    - [Controller resource](#controller-resource)\n  - [Resource addressability](#resource-addressability)\n  - [Resource representation](#resource-representation)\n- [API Design](#api-design)\n  - [Foundations](#foundations)\n    - [Include versions in URIs](#include-versions-in-uris)\n    - [Provide request ids for introspection](#provide-request-ids-for-introspection)\n    - [Healthchecks](#healthchecks)\n  - Partitioning functionality into APIs\n  - [Requests](#requests)\n    - [URI Paths](#uri-paths)\n    - [HTTP Verbs](#http-verbs)\n  - [Responses](#responses)\n    - [HTTP Status Codes](#http-status-codes)\n    - [Response Body](#response-body)\n- Load Balancing\n- Caching\n- [Security](#security)\n  - [Authentication](#authentication)\n  - [Authorization](#authorization)\n- [API Documentation](#api-documentation)\n- [Recipes](#recipes)\n  - [Filtering Resources](#filtering-resources)\n  - [Paginating Resources](#paginating-resources)\n  - [Sorting Resources](#sorting-resources)\n\n## Introduction\n\n### REST\n[REST](http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm) stands for Representational State Transfer, and it is an architectural style for distributed hypermedia systems. Ir was described by Roy Fielding in 2000 in his doctoral dissertation.\n\nA REST Application Programming Interface (REST API) is a type of web server that enables a client, either user-operated or automated, to access resources that model a system’s data and functions.\n\n### REST APIs\nWeb clients use APIs to communicate with Web Services. An API exposes data and functions to facilitate interactions between computer programs and allow them to exchange information.\n\nThe REST architectural style is commonly applied to the design of APIs for web services. A Web API conforming to the REST architectural style is a REST API, and it's said to be RESTful.\n\nA REST API consists of a set of interlinked resources. This set of resources is known as the REST API's resource model. A resource is an object with a certain type, associated data, relationships to other resources, and a set of methods that operate on it.\n\nThis style guide exposes our conventions for identifying resources and how the API make use of them.\n\n## Identifying REST Resources\nResources are the heart of the design of services. At the most basic level, a resource is an object that represents something that could map to a record in the database, a file, a searh result, or even a procedure.\n\n### Resource Types\nThere are 3 basic types of resources that can be defined:\n- Singleton resource\n- Collection resource\n- Controller resource\n\n### Singleton resource\nA singleton resource is akin to an object or a database record.\n\nFor instance, the following URI identify singleton resources:\n```\nhttps://my-domain.com/accounts/123/contact\nhttps://my-domain.com/accounts/123/profile\n```\n\n#### Collection resource\nA collection resource is a collection of other resources.\nIf we were considering a collection of accounts, each account by itself\nis a singleton resource.\n\nFor instance, the following URIs identify collection resources:\n```\nhttps://my-domain.com/accounts\nhttps://my-domain.com/accounts/123/subaccounts\n```\n\n#### Controller resource\nController resources model procedural concepts, similar to executable\nfunctions in the programming world.\n\nUsually in REST design, these kind of resources are the ones that cannot\nbe mapped to standard CRUD methods.\n\nThe name chosen for a controller resource typically appears as the last segment in a URI path, with no child\nresources to follow them in the hierarchy. The following example shows a controller resource\nthat allows a client to resend an invoice.\n\n```\nPOST https://my-domain.com/invoices/123/resend\n```\n\n### Resource addressability\nEvery resource needs a way to be referenced (or addressed). Uniform\nResource Identifiers (URIs) provide a way of doing this.\n\nFor instance, a URI that addresses an account resource could be:\n\n```\nhttps://my-domain.com/accounts/123\n```\n\nEach resource MUST have at least one URI that will identify it and\nprovide a way of addressing it. Keep in mind that a resource could be\nreferenced by more than more URI, but we encourage not to do this\nunless it is really necessary.\n\n### Resource Representation\nResources need a way to be represented. A representation is just the\nstream of bytes that exposes the resource.\n\nWe say that a representation is at the same time the format that the\nresource can take, and resources can have more than one representation.\nFor instance, text, HTML, JSON, XML, JPG, etc, or a custom format\ndefined by us.\n\n## API Design\n\n### Foundations\n\n#### Include versions in URIs\nRemember than an API is a contract between a publisher and a developer. To prevent surprise and breaking changes to users, it's best to require a version be specified in the URI of each request.\n\nWe suggest including the version information in the URI of every service request. As always, there are trade-offs. Other API designers prefer a more RESTful approach by using the `Accept` HTTP header to specify the version.\n\n```\nhttps://my-domain.com/api/v1/accounts\n```\n\nAPI versions should not change often. But when they do it,they should change the major version only:\n\n```\nhttps://my-domain.com/api/v2/accounts\n```\n\n#### Provide request ids for introspection\nWe suggest API designers to trace HTTP requests all the way from the\nclient to the backend. This can be done by including a custom `X-Request-Id` HTTP header in each API response, populated with a Universally Unique IDentifier (UUID) value. By logging these values on the client, server and any backing APIs, this provides a mechanism to trace, diagnose and debug requests.\n\nAs this ID is randomly generated by the client, it does not contain any sensitive information, and should thus not violate the user's privacy. At the same time, this does not help with tracking clients because the ID is created per request and not per client.\n\n#### Healthchecks\nSometimes a service instance can be incapable of handling requests yet still be running. For instance, it might have ran out of DB connections. When this occurs, the monitoring system should generate a alert.\n\nIn order to detect that a running service is unable to handle requests, we should provide healthcheck endpoints.\nThis will allow us to keep the impact on the performance of an application as low as possible.\nUsing business endpoints for this purpose would involve unnecessary processing time.\n\nIt's useful to expose different endpoints for different checks.\nEach project will have a different set of checks depending on its stack of technologies, and they will be available to be checked separately.\n\nEach of these checks can pass (response status `200`) or fail (response status `500`).\nIt's possible to define custom checks in case needed.\n\n```http\nRequest: GET https://my-domain.com/health/database.json\n\nResponse: 200 OK\nBody:\n{\n  \"database\": {\n    \"message\": \"Schema version: 20160317201558\",\n    \"success\": true,\n    \"time\": 0.0123434231\n  }\n}\n```\n\n```http\nRequest: GET https://my-domain.com/health/redis.json\n\nResponse: 500 Internal Server Error\nBody:\n{\n  \"redis\": {\n    \"message\": \"Error: 'getaddrinfo: nodename nor servname provided, or not known'\",\n    \"success\": false,\n    \"time\": 0.0123434231\n  }\n}\n```\n\nThere is also the possibility to check them all, getting a response with the summarized status.\nThis endpoint will respond with status `200` if all checks pass.\n\n```http\nRequest: GET https://my-domain.com/health/all.json\n\nResponse: 500 Internal Server Error\nBody:\n{\n  \"default\": {\n    \"message\": \"Application is running\",\n    \"success\": true,\n    \"time\": 0.00000999998883344233\n  },\n  \"database\": {\n    \"message\": \"Schema version: 20160317201558\",\n    \"success\": true,\n    \"time\": 0.013348999986192212\n  },\n  \"redis\": {\n    \"message\": \"Error: 'getaddrinfo: nodename nor servname provided, or not known'\",\n    \"success\": false,\n    \"time\": 0.0014479999954346567\n  },\n  \"app_version\": {\n    \"message\": \"Version: 1.2.0\",\n    \"success\": true,\n    \"time\": 0.0009160000190604478\n  }\n}\n```\n\n### Partitioning functionality into APIs\n\n### Requests\n\n#### URI paths\nURIs identify REST resources, they are the public interface of a\nAPI. Well-designed URI patterns make an API easy to consume, discover\nand extend.\n\nWe encourage you to build URIs for your resources following these\nguidelines:\n- Use only nouns or verbs for the paths.\n- Use:\n  - singular nouns for singular resources.\n  - plural nouns for collection resources.\n  - verbs for controller resources.\n- Describe resources in a language familiar to the business.\n- Use `snake_case` syntax.\n- Avoid deep nesting.\n\nResources that are deeply nested are generally painful to consume. You\nshouldn't need more than two levels deep:\n\n```\nGET /accounts  # :)\nGET /accounts/123/subaccounts  # :)\nGET /accounts/123/subaccounts/321  # :)\nGET /accounts/123/subaccounts/321/invoices  # :(\n```\n\n#### HTTP Verbs\nThe Uniform Interface is a big constraint at the time of implementing a\nREST API. It's goal is to make the interaction between components as\nsimple as possible.\n\nHTTP 1.1 provides a set of methods that are the verbs for this Uniform\nInterface:\n- `GET`\n- `POST`\n- `PUT`\n- `PATCH`\n- `DELETE`\n- `HEAD`\n- `OPTIONS`\n\nSome of the listed verbs are safe (do not request any server-side\neffects), whereas some other are idempotent (can be replayed any number\nof times without a change from the first one.\n\nWe encourage to use HTTP verbs for each action that is going to affect\nour resources. For instance, going back to our accounts example:\n\nVerb | Resource | Description | Safe | Idempotent\n---- | ---------| ----------- | ---- | ----------\nGET | /accounts | Get collection of accounts | Yes | Yes\nGET | /accounts/123 | Get account 123 | Yes | Yes\nPOST | /accounts | Create a new account with info sent in the body of the request | No | No\nPUT | /accounts/123 | Update account 123 | No | Yes\nPATCH | /accounts/123 | Partial update account 123 | No | Yes\nDELETE | /accounts/123 | Delete account 123 | No | No\n\n### Responses\n\n#### HTTP Status Codes\nHTTP provides three-digit integer status codes to specify the status of a response. RESTful APIs make use of these status code to reflect the outcome of the API response:\n\nStatus Code | Description\n----------- | -----------\n1xx | Informational status that states that the request has been received and is continuing.\n2xx | Success status. Means that the request has been received and accepted.\n3xx | Redirection status. In order to complete the request, further action needs to take place at a different URI.\n4xx | Client error status. The request has a wrong format or could not be completed because of another client issue.\n5xx | Server error status. The server failed to complete the request.\n\nIn the next table you will find some of the status code that we suggest\nusing to reflect the outcome of your API responses:\n\nStatus Code | Meaning | Description\n----------- | ------- | -----------\n200 | ok | The request has been completed and approved. This is a generig success case.\n201 | Created | The request was successful and the resource has been created.\n202 | Accepted | The request has been approved and accepted for processing, but has not been completed yet.\n204 | No Content | The request has been completed and approved, but there is no response body. This status code is sometimes used as a response for controller resources.\n303 | See Other | The response to the request can be found at a different URI.\n400 | Bad Request | The request could not be completed because it was incorrectly formatted (e.g.: syntax error).\n401 | Unauthorized | The request failed because the client was not authenticated.\n403 | Forbidden | The request failed because the client did not have authorization for the requested resource.\n404 | Not Found | The request failed because the resource does not exist.\n409 | Conflict | The request failed because of an edit conflict.\n422 | Unprocessable Entity | The request failed because it contained invalid parameteters. As opposed to 400 status code, 422 is returned when no format errors are present but a semantic error is present (e.g.: validation errors).\n500 | Internal Server Error | Something went wrong on the server.\n\n#### Response Body\n\n##### Timestamps for resources\nWe encourage providing `created_at` and `updated_at` timestamps for\nresources by default:\n\n```\n{\n  \"id\": 123,\n  ...\n  \"created_at\": \"2017-01-01T12:00:00Z\",\n  \"updated_at\": \"2017-01-01T12:00:00Z\"\n}\n```\n\nThe timestamps should be formatted in\n[ISO8601](https://www.iso.org/iso-8601-date-and-time-format.html).\n\n##### Successful Response Bodies\nBy default, response bodies hold the actual resource data (the\nresource's representation). It must have a valid format, and we suggest\nusing JSON in case your client is the browser.\n\nExample of an account resource:\n\n```\nRequest: GET /accounts/123\n\nResponse: 200 ok\nBody:\n{\n  \"id\": 123,\n  \"name\": \"Coca Cola\",\n  \"created_at\": \"2017-01-01T12:00:00Z\",\n  \"updated_at\": \"2017-01-01T12:00:00Z\"\n}\n```\n\nExample of a collection of accounts resource:\n\n```\nRequest: GET /accounts\n\nResponse: 200 ok\nBody:\n[\n  {\n    \"id\": 123,\n    \"name\": \"Coca Cola\",\n    \"created_at\": \"2017-01-01T12:00:00Z\",\n    \"updated_at\": \"2017-01-01T12:00:00Z\"\n  },\n  ...\n  {\n    \"id\": 900,\n    \"name\": \"GM\",\n    \"created_at\": \"2016-04-01T12:00:00Z\",\n    \"updated_at\": \"2017-01-01T12:00:00Z\"\n  }\n]\n```\n\n##### Error Response Bodies\nThe response body for error conditions must be simple and self\nexplanatory.\n\nValidation errors are returned in the body with a `422`\nstatus code. The body must have a simple layout and, at the same time be\nspecific about the fields that have an incorrect value:\n\n```\nRequest: POST /accounts\nBody:\n{\n  \"name\": \"\"\n}\n\nResponse: 422 Unprocessable Entity\nBody:\n{\n  \"name\": [\"cannot be blank\", \"is too short\"]\n}\n```\n\nWe encourage to return validation errors in a JSON that contains a key\nfor each attribute name, and an array of error messages for its value.\n\n## Security\nTo properly secure our APIs, we encourage you to implement Authentication and Authorization.\n\n### Authentication\nAuthentication refers to verifying that the client is who she says she is and that no one has tampered with her message.\n\nWhen a request fails because the client is not authenticated the status `401` (`Unauthorized`) should be returned.\n\n### Authorization\nAuthorization refers to determining what a given client is allowed to do on the system.\n\nWhen a request fails because the client does not have access to a specific resource, the status `403` (`Forbidden`) should be returned.\n\n\n## API Documentation\nAPI documentation is important. It explains to the clients what resources and endpoints the API is exposing, and how to consume them.\nAt the same time, it's a concise reference manual containing all the information required to work with the API.\n\n[Swagger](https://swagger.io/specification/) is the standard for documenting the APIs.\nA Swagger JSON file should be exposed by each API, describing its behaviour and all of its endpoints.\n\nSwagger's specification states that by convention, the Swagger file is named `swagger.json`.\n\n```\nGET https://my-domain.com/v1/swagger.json\n```\n\n## Recipes\nThe following recipes are meant to help with day-to-day design and implementation questions involving REST. They should not be taken as\ngospel but rather guide your discussions in solving real-world problems.\n\n### Filtering Resources\nComplex searches may require a DSL definition in order to make filtering.\nWhen dealing with simple filterings, we can take advantage of the query params to filter a resource by its attributes.\n\n```\nRequest: GET /accounts?name=Coke\n\nResponse: 200 OK\nBody:\n[\n  {\n    \"id\": 123,\n    \"name\": \"Coke\",\n    \"created_at\": \"2017-01-01T12:00:00Z\",\n    \"updated_at\": \"2017-01-01T12:00:00Z\"\n  }\n]\n```\n\nWe could do the same for nested resources:\n\n```\nRequest: GET /accounts?name=Coke\u0026primary_contact[email]=john@doe.com\n\nResponse: 200 OK\nBody:\n[\n  {\n    \"id\": 123,\n    \"name\": \"Coke\",\n    \"primary_contact\": {\n      \"first_name\": \"John\",\n      \"last_name\": \"Doe\",\n      \"email\": \"john@doe.com\"\n    },\n    \"created_at\": \"2017-01-01T12:00:00Z\",\n    \"updated_at\": \"2017-01-01T12:00:00Z\"\n  }\n]\n```\n\n### Paginating Resources\nCollection resources should be paginated to avoid big responses, and make them easier to handle.\nRequests are paginated using the `page` parameter. Omitting this parameter will return the first page.\n\n```\nRequest: GET /accounts?page=2\n\nResponse: 200 OK\nBody:\n[\n  {\n    \"id\": 123,\n    \"name\": \"Coke\",\n    \"created_at\": \"2017-01-01T12:00:00Z\",\n    \"updated_at\": \"2017-01-01T12:00:00Z\"\n  },\n  ...\n  {\n    \"id\": 222,\n    \"name\": \"Cars Inc\",\n    \"created_at\": \"2017-01-01T12:00:00Z\",\n    \"updated_at\": \"2017-01-01T12:00:00Z\"\n  }\n]\n```\n\nWe can control how many items are returned with each page using the `per_page` parameter.\nWe also suggest to give this parameter a default value.\n\n```\nRequest: GET /accounts?page=2\u0026per_page=2\n\nResponse: 200 OK\nBody:\n[\n  {\n    \"id\": 123,\n    \"name\": \"Coke\",\n    \"created_at\": \"2017-01-01T12:00:00Z\",\n    \"updated_at\": \"2017-01-01T12:00:00Z\"\n  },\n  {\n    \"id\": 124,\n    \"name\": \"Beds Inc\",\n    \"created_at\": \"2017-01-01T12:00:00Z\",\n    \"updated_at\": \"2017-01-01T12:00:00Z\"\n  }\n]\n```\n\n#### Link Header\nPagination info is included in the [Link Header](https://tools.ietf.org/html/rfc5988). It's important for consumers to follow these headers rather than construct their own URIs. Other information like `total count` and `per page` can be helpful for client applications.\n\n```\nRequest: GET /accounts?page=2\n\nResponse headers:\n...\nLink: \u003chttps://my-domain.com/accounts?page=1\u003e; rel=\"first\",\n      \u003chttps://my-domain.com/accounts?page=1\u003e; rel=\"prev\",\n      \u003chttps://my-domain.com/accounts?page=3\u003e; rel=\"next\",\n      \u003chttps://my-domain.com/accounts?page=4\u003e; rel=\"last\"\nX-Total-Count: 100\nX-Total-Pages: 4\nX-Per-Page: 25\nX-Page: 2\n```\n\nAvailable values for `rel`:\n| Name | Description |\n|------|-------------|\n| `first` | First page's URI |\n| `prev`  | Previous page's URI |\n| `next` | Next page's URI |\n| `last` | Last page's URI |\n\n\n### Sorting Resources\n`sort` and `sort_direction` are options for sorting resources. `sort` should be an attribute on the resource and `sort_direction` accepts `asc` or `desc`.\n\n```\nRequest: GET /accounts?sort=name\u0026sort_directio=asc\n\nResponse: 200 OK\nBody:\n[\n  {\n    \"id\": 100,\n    \"name\": \"Amazon\",\n    \"created_at\": \"2017-01-01T12:00:00Z\",\n    \"updated_at\": \"2017-01-01T12:00:00Z\"\n  },\n  {\n    \"id\": 123,\n    \"name\": \"Coke\",\n    \"created_at\": \"2017-01-01T12:00:00Z\",\n    \"updated_at\": \"2017-01-01T12:00:00Z\"\n  },\n  ...\n  {\n    \"id\": 432,\n    \"name\": \"Zoho\",\n    \"created_at\": \"2017-01-01T12:00:00Z\",\n    \"updated_at\": \"2017-01-01T12:00:00Z\"\n  }\n]\n```\n\n\n## TODOs\n- Give example about merge resource.\n- Load Balancing\n- Caching\n- Enhance Security section\n- Recipes\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmerodriguezblanco%2Frest-api-style-guide","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fmerodriguezblanco%2Frest-api-style-guide","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmerodriguezblanco%2Frest-api-style-guide/lists"}