Giter VIP home page Giter VIP logo

openapi-style-guide's Introduction

The OpenAPI Initiative Style Guide

How to (and how not to) refer to the OAI in meetups, interviews, casual conversations, the settling of bar bets, and for conference presentations.

The Specification Name and Usage

OpenAPI Specification refers the name of the popular API description format. It contains ONE space and FIVE capital letters. Following the first instance, it may be referred to as:

  • OAS: for example, "Can you send us your OAS document?"

  • Specification: for example "Can you send me your specification?" (may be abbreviated less formally as "spec")

  • OpenAPI (when referring to the format in comparison to another): such as "OpenAPI has a different signature mechanism than WSDL."

In order to connect readers familiar with the former name of the specification it may be introduced as, "The OpenAPI Specification, formerly known as the Swagger specification." (Note that if Swagger is mentioned in this way, it should be accompanied by the word "specification" as Swagger remains SmartBear's trademark for certain open source tools.)

The Initiative Name and Usage

The OpenAPI Initiative refers to the organization that oversees the specification. It must contain ONE space and FIVE capital letters. After the initial declaration, it may be referred to as the "OAI" in subsequent references, for example:

  • The OpenAPI Specification (OAS) provides an open governance model, as directed by the OpenAPI Initiative's charter. The specification, although managed by the OAI, is not the same as the initiative itself.

Guidelines for Naming Projects, Tools, or Organizations

If you are creating something that works with or depends upon the OpenAPI Specification, you may decide you would like to use OpenAPI in the name of said thing. In these cases, it is important to consider whether your audience might confuse your effort as being under the auspices of the OpenAPI Initiative. Ask yourself, "Might someone think this was an official tool/project/group of the OAI?" If the answer is, "Maybe," then consider adding a modifier. For example, OpenAPI Tools vs OpenAPI-based Tools or even Tools for OpenAPI. If you're uncertain, please reach out via Twitter or email, and we can help work through it with you.

Similarly, you may wish to have a graphic that uses the colors or visual themes of the OpenAPI logo. Again, tread carefully, as it is important for the community that the OAI maintain a strong, recognizable brand. For example, if you're considering using the barbell element or the segmented circle, you may want to reach out to the OAI proactively to avoid a rebranding exercise later.

References to Teams in the Project

As per the charter, the OpenAPI Initiative (OAI) provides an open source, technical community, within which industry participants may contribute to building a vendor-neutral, portable, and open specification for providing technical metadata for REST APIs — the OpenAPI Specification (OAS). The following named groups may be properly referred to as:

  • Business Governance Board ("BGB", second reference)

    • Comprised of official corporate entities (companies, schools, non-profits, etc.) who have signed the official project membership agreement to be members of the OpenAPI Initiative and are bound by the laws governed by the project’s charter. [Read more here]
  • Technical Steering Committee ("TSC", second reference)

    • The Technical Steering Committee (TSC) is open to any developer, end user or subject matter expert that participates in the activities of OAI, regardless of whether the participant is employed by an OAI member company. Influence on the evolution of the OAS comes by engaging with the TSC in technical discussions and by contributing to the project. [Read more here]
    • The OAI board approved a name change of this body from the Technical Developer Community to the Technical Steering Committee as of Feb. 8, 2018.
  • Technical Oversight Board ("TOB", second reference)

    • The Technical Oversight Board (TOB) is responsible for managing conflicts, violations of procedures or guidelines and any cross-project or high-level issues that cannot be resolved in the TSC for the Specification. The TOB shall also be responsible for adding, removing or re-organizing OAI Projects. The TOB shall not dictate or interfere with the day-to-day work of individual OAI Projects or their decisions. [Read more here]

Linux Foundation

The OpenAPI Initiative is one of the Linux Foundation's Collaborative Projects, which are independently funded software projects that harness the power of collaborative development to fuel innovation across industries and ecosystems.

  • What is a Linux Foundation Collaborative Project?

    • Collaborative Projects are independently funded software projects that harness the power of collaborative development to fuel innovation across industries and ecosystems. By spreading the collaborative DNA of the largest collaborative software development project in history, The Linux Foundation provides the essential collaborative and organizational framework so project hosts can focus on innovation and results. Linux Foundation Collaborative Projects span the enterprise, mobile, embedded and life sciences markets and are backed by many of the largest names in technology. For more information about Linux Foundation Collaborative Projects, please visit: [Read more here]
  • What is the Linux Foundation?

    • The Linux Foundation is a nonprofit consortium dedicated to fostering the growth of Linux and collaborative software development. Founded in 2000, the organization sponsors the work of Linux creator Linus Torvalds and promotes, protects and advances the Linux operating system and collaborative software development by marshaling the resources of its members and the open source community. The Linux Foundation provides a neutral forum for collaboration and education by hosting Collaborative Projects, Linux conferences including LinuxCon, and generating original research and content that advances the understanding of Linux and collaborative software development. More information can be found at [Read more here].

Graphics

This repository contains color (Pantone), black, and white versions of the OpenAPI Initiative's logo in both vector and bitmap. Whenever possible, prefer the color logo, though white or black treatments may be considered more appropriate under certain conditions, and the lettering may be omitted where a purely graphical representation is required. When using a graphic to represent the OpenAPI Specification rather than the OpenAPI Initiative, consider using the logos named OpenAPI_Specification_Logo_* or omit the lettering on the main OAI logo. The OpenAPI logos should not be deformed or used in a way that may be considered disrespectful.

The official Pantone swatches are also available for reference.

A Short History of the OpenAPI Initiative and the OpenAPI Specification

On Nov. 5, 2015, SmartBear in conjunction with 3Scale, Apigee, Capital One, Google, IBM, Intuit, Microsoft, PayPal, and Restlet announced the formation of the OpenAPI Initiative, an open source project under the Linux Foundation. As part of the formation of the OAI, SmartBear donated the Swagger specification to the Linux Foundation, meaning that the OpenAPI Specification is semantically identical to the specification formerly known as the Swagger 2.0 specification. It is widely recognized as the most popular open source framework for defining and creating RESTful APIs, and today tens of thousands of developers are building thousands of open source repos of tools leveraging the OpenAPI Specification. In 2010, the Swagger specification was created by Wordnik, who published it under an open source license one year later. In March of 2015, SmartBear acquired Wordnik's interests in the Swagger projects from its parent company, Reverb Technologies.

openapi-style-guide's People

Contributors

atlc avatar earth2marsh avatar frankkilcommins avatar namdeirf avatar webron avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

openapi-style-guide's Issues

Grammar in initiative example

The text here is just a bit heavy-handed...

Among the concerns are the example of usage of the name of the initiative: "is are not one the same as the initiative itself."

Organize and consolidate name & logo usage guidelines, 3rd-party branding guidelines

This Style Guide now provides some guidelines for the use of the OpenAPI name in the branding of projects, tools, and organizations outside the OAI itself, and the use of logos resembling the OpenAPI logo in such projects.

However, I had a hard time finding guidelines for appropriate usage of the OpenAPI logo itself.

It turns out that the usage guidelines seem to be in three different places:

  • This OpenAPI Style Guide
    • Sourced from the README file
    • This is the only page that has the new 3rd-party branding guidelines.
  • The FAQ / Style Guide page on the OpenAPIs.org website.
    • That page looks like it might have been sourced from an earlier revision of this style guide.
    • I don't see a link from that page to this style guide project on GitHub, only to the logos. The page content includes a mention of "this repository," but the page appears outside of any repository.
  • The FAQ / FAQ page on the OpenAPIs.org website.
    • That page refers to (but doesn't actually link to) the Linux Foundation Trademark Usage page.
    • That page is the only one that contains requirements for trademark symbols and attribution notices, which may be important to mention in any context that describes appropriate usage.
    • That page is also the only one that describes general guidelines for appropriate use of the OpenAPI logo.
    • It also contains a guideline for third-party usage that is expressed somewhat differently from the naming guidelines in this Style Guide:

      Use is NOT acceptable if a company is stating, or implying, that OAS is a mark of an org besides the LF. For example, entities should ensure that their own product names and logos are larger than OAI/LF – OpenAPI Initiative and OpenAPI Specification should not be the most prominent name or logo on their materials.

There's quite a bit of overlap across these pages. There are likely some inconsistencies. They don't seem to be cross-linked in a methodical way. A person looking at any one of these pages probably won't know to look at the others to get the full picture. They would reasonably assume that the guidelines they see are complete and definitive.

I think we should look at this carefully and try to make it more DRY, so there's exactly one authoritative source for information about appropriate use of the OpenAPI names and logos, along with the related third-party branding guidelines.

No XML attribute generated for attribute

I have the following XML:
<xs:element name="CancelRequest" nillable="true" type="CancelRequest" /> <xs:complexType name="CancelRequest"> <xs:sequence> <xs:element minOccurs="1" maxOccurs="1" name="OrderID" type="xs:string" /> </xs:sequence> <xs:attribute name="version" type="xs:string" /> </xs:complexType>
The corresponding Java class has ben generated using xjc:
`@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "CancelRequest", propOrder = {
"orderID"
})
@XmlRootElement(name = "CancelRequest")
public class CancelRequest
implements Serializable, ToString
{

private final static long serialVersionUID = -1L;
@XmlElement(name = "OrderID", required = true)
protected String orderID;
@XmlAttribute(name = "version")
protected String version;

rest of class are getters and setters`

The code generated by Swagger is
"CancelRequest": { "type": "object", "required": [ "orderID" ], "properties": { "orderID": { "type": "string", "xml": { "name": "OrderID" } }, "version": { "type": "string" } }, "xml": { "name": "CancelRequest" } },

There are no XML Object values generated for version. I would have expected here:
"xml": { "attribute":true }
Since version is an attribute.

"Guidelines for Naming Projects, Tools, or Organizations" section in the readme

With commit 7687728 a new section "Guidelines for Naming Projects, Tools, or Organizations" was introduced in the README. This issue is about understanding the consequences.


Found on GitHub:

GitHub Organization:

Several GitHub Organizations are already using OpenAPI as prefix:
https://github.com/OpenAPI
https://github.com/OpenApiFactory
https://github.com/OpenAPITools
https://github.com/OpenAPI-Tools-Automation
https://github.com/openapi-test
https://github.com/openapi-ro

Project name:

Several GitHub projects are already OpenAPI or openapi in their project name:
https://github.com/contentjet/openapi-ui
https://github.com/getkin/kin-openapi
https://github.com/oasis-tcs/odata-openapi
https://github.com/Mermade/openapi-codegen
https://github.com/Mermade/openapi-filter
https://github.com/Mermade/swagger2openapi
https://github.com/Microsoft/OpenAPI.NET
https://github.com/openapitools/openapi-generator
https://github.com/p1c2u/openapi-spec-validator
https://github.com/quen2404/openapi-diff
https://github.com/RepreZen/KaiZen-OpenAPI-Editor
https://github.com/RepreZen/KaiZen-OpenApi-Parser
https://github.com/xuzhg/OData.OpenAPI

Is the usage of open-api in the project URL better?
https://github.com/eclipse/microprofile-open-api (Project title in the readme: "Eclipse MicroProfile OpenAPI")
https://github.com/janephp/open-api (Project title in the readme: "Jane OpenAPI"

And some projects are using openapi3:
https://github.com/metadevpro/openapi3-ts
https://github.com/adwhit/openapi3-rust


While I understand the concern about the usage of the OpenAPI brand in third-party projects, I think that the rule as formulated in the readme is really hard to implement. There are a lot of projects out there (small one, big corporation one, foundation-backed one). I think that the having a lot of projects having adopted "OpenAPI" in their project names demonstrate the strength of the ecosystem.

Thank you in advance for your advises on how to read the section.

Terminology explanation in README

Currently the README contains this:

Specification: for example "Can you send me your specification?" (may be abbreviated less formally as "spec")

It seems like this either refers to an older use of terms when it was ok to call a "definition" a "specification". Or if it really means that I am asking somebody to send me the OpenAPI specification, then this may not be the most helpful example. What about:

Specification: for example "My OpenAPI document conforms to the OpenAPI specification version 3.1.0"

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.