To provide quality solutions to common technical tasks via cookbooks in the context of guidelines and current best practices.
The goal of this project is to provide a useful resource for developers and solution architects in construction of application programming interfaces for use at Rackspace. Additionally, guidelines and, where appropriate, consistency standards are provided in order to provide a more uniform environment across the company, which is hoped to facilitate interoperability between teams.
The following kinds of artifacts are in-scope for this project:
A cookbook recipe is a document focused on describing a common pattern (need or problem) and recommended solution(s) for the common pattern.
Recipes describe best practices for supporting standards and guidelines.
A guideline is a piece of advice that may be objective or subjective but should be followed unless there is good reason not to.
A standard is a specific rule that can be objectively satisfied and implemented. A standard should always be implemented by services. A standard should not be abstract, but should be specific enough that it can be verified by a machine.
Some of the best ways to contribute are to try things out, create issues, and join in design conversations.
Want to get more familiar with what's going on?
Looking for something to work on? The list of issues is a great place to start. See some of our guides for more details:
You are also encouraged to start a discussion by filing an issue or creating a gist.
Category | Title | Last Revised | Content |
---|---|---|---|
api review | api review | no | |
communication and planning | readme | no | |
communication and planning | communication and planning | yes | |
documentation | readme | no | |
documentation | documentaton-standards | yes | |
documentation | raml-standards-and-practices | yes | |
language-framework | language-and-framwork-service-guidelines | no | |
monitoring | readme | no | |
performance | readme | no | |
performance | performance | yes | |
quality | readme | no | |
quality | quality-standards | yes | |
references | readme | no | |
representaion design | readme | yes | |
representaion design | account-and-device-references | yes | |
representaion design | json-hateoas-links | yes | |
representaion design | json-representations | yes | |
representaion design | representation-design | yes | |
resource design | readme | yes | |
resource design | common-resource-patterns | yes | |
resource design | pagination-design | yes | |
resource design | sorting | yes | |
resource design | uri-design | yes | |
security | readme | no | |
security | security | yes | |
service design | readme | yes | |
service design | design-patters-for-services | yes | |
service design | rackspace-restful-web-services | yes | |
service design | references | yes | |
service design | rest-service-scoring-guide | yes | |
service design | service-anti-patterns | yes | |
service design | thoughts-on-soa-standards | yes | |
service design | why-design-for-rest-now | yes | |
service design | wrapping-vendor-applications | yes |
Cookbook | Last Revised | Content |
---|---|---|
Approach to Integration | yes | |
Atom feed paging and archiving | yes | |
Conditionally enabling users based on business rules in an api | yes | |
Contract versioning | yes | |
Cookbooks | yes | |
Correct use of http verbs | yes | |
general xml schema guidance | yes | |
how to implement hateoas | yes | |
identifying resources with uris | yes | |
paging event collections | yes | |
publishing api docs to github | yes | |
restful resource compositions | yes | |
service data synchronization | yes | |
service hostname conventions | yes | |
supporting http cache validation | yes | |
using caching in a restful service implementation | yes | |
using database caching | yes | |
using http headers for expiration caching | yes | |
using http proxy caching | yes | |
using media types | yes | |
using page and fragment caching | yes | |
using repose for api rate limiting | yes | |
when to use an application integration technology that is not restful | yes | |
when to use atom-hopper | yes |