Esta defini\u00e7\u00e3o \u00e9 um pouco complicada. Vamos decompor a descri\u00e7\u00e3o do SmartBear em peda\u00e7os menores:<\/p>\r\n
1.\u201c\u2026define uma intercafe padr\u00e3o\u2026\u201d:<\/strong><\/p>\r\n A especifica\u00e7\u00e3o do OpenAPI define a estrutura de uma API que tamb\u00e9m descreve a API.<\/p>\r\n 2. \u201c\u2026interface padr\u00e3o de linguagem para APIs RESTful\u2026\u201d:<\/strong><\/p>\r\n 3. \u201c\u2026Que permite que pessoas e computadores descubram e compreendam as capacidades do servi\u00e7o\u2026\u201d:<\/strong><\/p>\r\n 4. \u201c\u2026Sem acesso ao c\u00f3digo-fonte, \u00e0 documenta\u00e7\u00e3o ou \u00e0 inspe\u00e7\u00e3o do tr\u00e1fego de rede.\u201d<\/strong><\/p>\r\n Com a OpenAPI, o aplicativo do cliente e o servidor de API s\u00e3o separados. A defini\u00e7\u00e3o de API de um servi\u00e7o define como os clientes podem interagir com ele sem a necessidade de o cliente ler seu c\u00f3digo-fonte.<\/p>\r\n Em resumo, a OpenAPI \u00e9 uma especifica\u00e7\u00e3o de API RESTful<\/a> que descreve APIs em conformidade com a arquitetura RESTful. Uma especifica\u00e7\u00e3o fornece uma interface para permitir que humanos e computadores entendam uma API e como interagir com ela.<\/p>\r\n As origens da OpenAPI come\u00e7aram com o engenheiro Tony Tam, da empresa Wordnik, em 2009. Tony criou uma especifica\u00e7\u00e3o (chamada Swagger na \u00e9poca) que descreveria a API JSON do dicion\u00e1rio on-line da Wordnik.<\/p>\r\n O Swagger foi submetido a v\u00e1rias itera\u00e7\u00f5es por Tony nos anos seguintes. No entanto, o Swagger 2.0 registrou um aumento na ado\u00e7\u00e3o da especifica\u00e7\u00e3o e desencadeou a cria\u00e7\u00e3o de ferramentas para analisar a especifica\u00e7\u00e3o.<\/p>\r\n Em 2015, a SmartBear adquiriu o Swagger. A SmartBear \u00e9 a empresa que atualmente \u00e9 propriet\u00e1ria do Swagger. A especifica\u00e7\u00e3o Swagger foi renomeada como \u201cOpenAPI\u201d para refletir a nova iniciativa OpenAPI. Essa renomea\u00e7\u00e3o \u00e9 a raz\u00e3o pela qual o \u201cSwagger\u201d \u00e9 confundido com o padr\u00e3o \u201cOpenAPI\u201d.<\/p>\r\n Na \u00e9poca, um grupo de empresas reconheceu que o setor precisava de uma forma padronizada e neutra em rela\u00e7\u00e3o aos fornecedores para descrever as APIs. O setor precisava fornecer \u201cpr\u00e1ticas recomendadas\u201d para o setor e supervisionar as atualiza\u00e7\u00f5es da OpenAPI ao longo do tempo.<\/p>\r\n Essas empresas estabeleceram a Iniciativa OpenAPI como um programa de governan\u00e7a da Linux Foundation que mant\u00e9m o padr\u00e3o OpenAPI e fornece orienta\u00e7\u00f5es pr\u00e1ticas. As empresas fundadoras que formaram a iniciativa OpenAPI foram CapitalOne, PayPal, SmartBear, IBM, 3Scale, Google, Apigee, Intuit, Microsoft e Restlet. Desde ent\u00e3o, o n\u00famero de empresas que participam da iniciativa cresceu consideravelmente.<\/p>\r\n O Comit\u00ea de Dire\u00e7\u00e3o T\u00e9cnica agora gerencia a OpenAPI e continua a lan\u00e7ar novas vers\u00f5es com base no feedback da comunidade.<\/p>\r\n Existem v\u00e1rias especifica\u00e7\u00f5es dispon\u00edveis que descrevem APIs RESTful. O OpenAPI est\u00e1 entre os mais bem conhecidos e amplamente utilizados. Os outros dois formatos usados para REST APIs s\u00e3o RAML e API Blueprint. Abordaremos as vantagens e desvantagens do OpenAPI mais tarde. Embora o OpenAPI possa ser considerado o padr\u00e3o da ind\u00fastria, no final, as empresas muitas vezes escolhem o formato que melhor se adapta \u00e0s suas necessidades de neg\u00f3cios.<\/p>\r\n Ent\u00e3o, isso requer a pergunta: se h\u00e1 v\u00e1rios formatos dispon\u00edveis para descrever REST APIs, por que a OpenAPI \u00e9 t\u00e3o especial? Um fator chave para porque o OpenAPI \u00e9 t\u00e3o popular \u00e9 a sua ado\u00e7\u00e3o. Mais ado\u00e7\u00e3o leva a mais apoio comunit\u00e1rio, ferramentas robustas e uma governa\u00e7\u00e3o mais eficaz.<\/p>\r\n Uma empresa pode usar a especifica\u00e7\u00e3o do OpenAPI para sua portabilidade e simplicidade. A OpenAPI \u00e9 “language-agnostic” e define uma linguagem comum para a comunica\u00e7\u00e3o cliente-servidor. \u00c9 altamente compat\u00edvel com sistemas escritos em diferentes linguagens de programa\u00e7\u00e3o. A OpenAPI tamb\u00e9m \u00e9 altamente leg\u00edvel para seres humanos e computadores e tem o apoio de uma grande comunidade em crescimento.<\/p>\r\n Outro formato popular \u00e9 o RAML, uma linguagem de modelagem de API com foco na defini\u00e7\u00e3o e no design de APIs (embora voc\u00ea possa projetar APIs com OpenAPI). Os recursos da RAML podem parecer inferiores aos da OpenAPI. Ela tem a vantagem de ser hier\u00e1rquica e suportar a heran\u00e7a do modelo de dados. No entanto, a RAML n\u00e3o \u00e9 t\u00e3o amplamente adotada quanto a OpenAPI. Embora a RAML tenha uma comunidade dedicada, ela tem menos suporte da comunidade. A RAML tem ferramentas, mas h\u00e1 algumas indica\u00e7\u00f5es de que as vers\u00f5es mais recentes n\u00e3o t\u00eam o suporte necess\u00e1rio.<\/p>\r\n Al\u00e9m da RAML, o API Blueprint \u00e9 outra alternativa \u00e0 OpenAPI. O API Blueprint se concentra em uma documenta\u00e7\u00e3o clara com base no formato markdown, em vez de JSON (como OpenAPI) ou YAML (como OpenAPI e RAML). Devido \u00e0 sua baixa ado\u00e7\u00e3o, o API Blueprint n\u00e3o tem suporte da comunidade e ferramentas robustas para OpenAPI. A integra\u00e7\u00e3o do API Blueprint em todo o ciclo de vida da API<\/a> \u00e9 dif\u00edcil porque seu \u00fanico foco \u00e9 a documenta\u00e7\u00e3o.<\/p>\r\n Em resumo, a OpenAPI \u00e9 o padr\u00e3o mais popular para a descri\u00e7\u00e3o de APIs. Embora tenha desvantagens, a ado\u00e7\u00e3o da OpenAPI provavelmente crescer\u00e1, enquanto a viabilidade de longo prazo de outros tipos de especifica\u00e7\u00e3o \u00e9 incerta.<\/p>\r\n Pense em um documento de especifica\u00e7\u00e3o de legado que voc\u00ea leria no formato Microsoft Word (.docx). Esse documento de especifica\u00e7\u00e3o de legado fornece o contexto geral de um sistema e descreve seus componentes e intera\u00e7\u00f5es com outros sistemas.<\/p>\r\n A estrutura das especifica\u00e7\u00f5es do legado geralmente varia. Uma especifica\u00e7\u00e3o de API, como a OpenAPI, \u00e9 estritamente estruturada. Se uma especifica\u00e7\u00e3o de API estiver em conformidade com outro formato, como RAML ou API Blueprint, a documenta\u00e7\u00e3o ter\u00e1 uma estrutura que adere a esse formato.<\/p>\r\n Voltando \u00e0 forma como a OpenAPI define uma API, voc\u00ea ouvir\u00e1 com frequ\u00eancia \u201cespecifica\u00e7\u00e3o\u201d e \u201cdefini\u00e7\u00e3o\u201d usadas como sin\u00f4nimos. Uma especifica\u00e7\u00e3o de API \u201cdefine\u201d uma API. Ao ler uma especifica\u00e7\u00e3o de API, voc\u00ea aprende sobre os tipos de solicita\u00e7\u00f5es que pode enviar e as respostas que espera receber da API. Al\u00e9m disso, a especifica\u00e7\u00e3o descreve as op\u00e7\u00f5es dispon\u00edveis que afetam as informa\u00e7\u00f5es retornadas. Como em uma especifica\u00e7\u00e3o herdada, voc\u00ea aprende sobre um sistema, seus componentes e suas intera\u00e7\u00f5es.<\/p>\r\n Outra diferen\u00e7a entre as especifica\u00e7\u00f5es de legado e as especifica\u00e7\u00f5es de API \u00e9 que as especifica\u00e7\u00f5es de API s\u00e3o din\u00e2micas. Sempre que o c\u00f3digo-fonte subjacente de uma API \u00e9 alterado, a documenta\u00e7\u00e3o \u00e9 atualizada. Os documentos de especifica\u00e7\u00e3o herdados exigem a atualiza\u00e7\u00e3o manual de documentos do Word sempre que o sistema \u00e9 alterado.<\/p>\r\n Antes de entender a estrutura de uma especifica\u00e7\u00e3o da OpenAPI, voc\u00ea deve entender o formato de um documento da OpenAPI. Ao contr\u00e1rio das especifica\u00e7\u00f5es legado escritas em Word, o formato da OpenAPI \u00e9 JSON. Embora a discuss\u00e3o das nuances do JSON esteja fora do escopo desta postagem do blog, pense no JSON como uma forma de representar os dados de uma API como pares de valores-chave.<\/p>\r\n Por exemplo, em especifica\u00e7\u00f5es legadas, voc\u00ea escreveria o t\u00edtulo de uma especifica\u00e7\u00e3o (incluindo o nome do sistema) usando um estilo de t\u00edtulo na p\u00e1gina de rosto. Para escrever o t\u00edtulo de uma especifica\u00e7\u00e3o da OpenAPI, por outro lado, voc\u00ea escreveria o t\u00edtulo como um par de valores-chave JSON.<\/p>\r\n Agora, pense em todas as informa\u00e7\u00f5es sobre uma API. Seus m\u00e9todos, opera\u00e7\u00f5es, respostas, etc. Imagine todas essas propriedades documentadas em uma s\u00e9rie desses pares de valores-chave que seguem a estrutura da OpenAPI.<\/p>\r\n Observa\u00e7\u00e3o:<\/strong> embora o JSON seja o formato padr\u00e3o da OpenAPI, \u00e9 poss\u00edvel representar a OpenAPI em YAML (um acr\u00f4nimo que significa YAML n\u00e3o \u00e9 linguagem de markup) mais simples.<\/p>\r\n Como um objeto JSON, a especifica\u00e7\u00e3o OpenAPI \u00e9 compat\u00edvel com os tipos de dados definidos na especifica\u00e7\u00e3o mais ampla do esquema JSON. Os prim\u00f3rdios incluem inteiros, n\u00fameros, booleanos e cadeias de caracteres. Voc\u00ea pode declarar o formato de um tipo de dados usando o formato da propriedade modificadora. Por exemplo, voc\u00ea pode declarar um inteiro como formato int32 ou int64, um n\u00famero como float ou double, ou uma cadeia de caracteres como formato bin\u00e1rio, de dados, de data e hora ou de senha. A OpenAPI tamb\u00e9m oferece suporte a modelos (objetos) definidos na especifica\u00e7\u00e3o JSON mais ampla como objetos de esquema.<\/p>\r\n \u00c9 importante observar que o JSON \u00e9 o principal formato que as APIs REST usam para enviar e receber informa\u00e7\u00f5es.<\/p>\r\n At\u00e9 agora, compreendemos que:<\/p>\r\n Agora, \u00e9 hora de discutir a estrutura do OpenAPI.<\/p>\r\n Como mencionado anteriormente, um documento OpenAPI est\u00e1 estritamente estruturado. Objetos ou matrizes de objetos de pares de chave-valor relacionados. Os objetos de alto n\u00edvel de uma especifica\u00e7\u00e3o do OpenAPI s\u00e3o como os cap\u00edtulos de um documento de especifica\u00e7\u00e3o legado.<\/p>\r\n Abaixo est\u00e1 um modelo OpenAPI<\/strong> com se\u00e7\u00f5es recolhidas para mostrar a estrutura geral. Toda se\u00e7\u00e3o tem propriedades, ou pares de valor chave, que fornecem metadados sobre a API.<\/p>\r\n O n\u00edvel superior do OpenAPI, indicado pelos primeiros conjuntos de par\u00eanteses { }, \u00e9 chamado de “objeto de documento”, porque cont\u00e9m todas as propriedades da OpenAPI.<\/p>\r\n Enquanto os documentos do OpenAPI devem estar de acordo com uma estrutura b\u00e1sica, o OpenAPI oferece alguma flexibilidade. Algumas das se\u00e7\u00f5es de alto n\u00edvel s\u00e3o necess\u00e1rias, enquanto outras n\u00e3o. Voc\u00ea vai notar especifica\u00e7\u00f5es do OpenAPI para diferentes APIs podem se parecer um pouco diferentes.<\/p>\r\n Um documento OpenAPI pode conter as seguintes se\u00e7\u00f5es:<\/p>\r\n Na parte inferior da sua documenta\u00e7\u00e3o da API, existe normalmente uma se\u00e7\u00e3o Schemas que corresponde ao esquema descrito na se\u00e7\u00e3o de componentes da defini\u00e7\u00e3o da API. O OpenAPI tem as seguintes vantagens:<\/p>\r\n Cada tipo de especifica\u00e7\u00e3o tem suas for\u00e7as e fraquezas. Aqui, vamos nos concentrar nas desvantagens da OpenAPI em compara\u00e7\u00e3o com seu rival mais pr\u00f3ximo, RAML.<\/p>\r\n Voc\u00ea pode adotar uma abordagem \u201cspec-first\u201d para projetar uma API com base na OpenAPI. Essa abordagem envolve escrever a especifica\u00e7\u00e3o da OpenAPI para uma API \u201c\u00e0 m\u00e3o\u201d ou usar uma ferramenta de design. Usando essa abordagem, voc\u00ea projeta a especifica\u00e7\u00e3o de uma API e, em seguida, usa a especifica\u00e7\u00e3o como um \u201ccontrato\u201d ao criar a API. O oposto de \u201cspec-first\u201d \u00e9 usar a OpenAPI para gerar documenta\u00e7\u00e3o sem us\u00e1-la como uma ferramenta de design.<\/p>\r\n Embora a abordagem \u201cspec-first\u201d tenha muitas vantagens, a OpenAPI geralmente n\u00e3o vem antes do desenvolvimento da API.<\/p>\r\n A estrutura hier\u00e1rquica da RAML pode se prestar mais a ser uma ferramenta de projeto e planejamento. Dessa forma, a RAML pode ser mais compat\u00edvel com a abordagem \u201cspec-first\u201d do que a REST. No final, a RAML \u00e9 comercializada como uma ferramenta de \u201cmodelagem de dados\u201d e \u201cdescri\u00e7\u00e3o\u201d de API, enquanto o Swagger \u00e9 a \u00faltima. O modelo hier\u00e1rquico do RAML ser\u00e1 discutido com mais detalhes na pr\u00f3xima se\u00e7\u00e3o.<\/p>\r\n Um dos conceitos principais para os padr\u00f5es de defini\u00e7\u00e3o de API como OpenAPI e RAML \u00e9 a capacidade de criar objetos de dados e relacion\u00e1-los entre si. O OpenAPI usa esquemas para este prop\u00f3sito e suporta os tipos de dados integrados do JSON. RAML usa um sistema de tipos para salvar propriedades associadas e promover a reutiliza\u00e7\u00e3o em toda a especifica\u00e7\u00e3o. Tamb\u00e9m suporta os mesmos tipos de dados internos que o OpenAPI.<\/p>\r\n A OpenAPI n\u00e3o tem uma estrutura hier\u00e1rquica \u201cverdadeira\u201d. O que voc\u00ea deseja de uma estrutura hier\u00e1rquica que descreva sua API? Idealmente, voc\u00ea quer um sistema para associar seus modelos de dados que seja:<\/p>\r\n O sistema de tipos da RAML se presta a ser um sistema mais hier\u00e1rquico do que o REST. De acordo com o Readme da RAML no GitHub, O uso da RAML de \u201ctipos de recursos e caracter\u00edsticas minimiza a repeti\u00e7\u00e3o em um RESTful design API e promove a consist\u00eancia dentro e atrav\u00e9s das APIs. Discutiremos a seguir o sistema de tipos da RAML.<\/p>\r\n Tipos de objeto RAML podem herdar outros tipos de objetos. Enquanto os esquemas OpenAPI podem “referenciar” esquemas, ele n\u00e3o suporta tecnicamente a heran\u00e7a como a RAML. Digo “tecnicamente” porque voc\u00ea pode ligar um esquema a outro usando uma refer\u00eancia do esquema (o marcador $ref). No entanto, a RAML vai mais longe. Voc\u00ea pode estabelecer rela\u00e7\u00f5es entre modelos de dados e evitar a repeti\u00e7\u00e3o de propriedades compartilhadas. Com OpenAPI, esquemas n\u00e3o est\u00e3o associados uns aos outros de forma hier\u00e1rquica como a RAML. Tipos RAML t\u00eam heran\u00e7a “verdadeira”, onde voc\u00ea pode estabelecer rela\u00e7\u00f5es entre pais e filhos entre modelos de dados.<\/p>\r\n O uso dos tipos RAML como modelos de dados o torna mais visual e facilmente leg\u00edvel do que o OpenAPI. Voc\u00ea pode ver facilmente a rela\u00e7\u00e3o entre tipos e suas propriedades compartilhadas.<\/p>\r\n RAML, como uma ferramenta mais visual, promove um planejamento a longo prazo para coisas como respostas simuladas no servidor, consoles API e muito mais. Pode ser tamb\u00e9m antecipar e planejar futuras melhorias na API utilizando a RAML.<\/p>\r\n A OpenAPI s\u00f3 pode descrever APIs RESTful. A RAML tem o benef\u00edcio adicional de oferecer suporte a outras arquiteturas al\u00e9m da REST, como RPC ou SOAP, desde que usem o protocolo HTTP. A flexibilidade do RAML permite que voc\u00ea o use como uma ferramenta de documenta\u00e7\u00e3o para arquiteturas al\u00e9m da REST.<\/p>\r\n A melhor maneira de aprender a OpenAPI \u00e9 adoptar uma abordagem pr\u00e1tica. Algumas ferramentas permitem editar especifica\u00e7\u00f5es do OpenAPI e, em seguida, gerar documenta\u00e7\u00e3o da API. A especifica\u00e7\u00e3o Swagger Petstore \u00e9 um exemplo de um documento OpenAPI.<\/p>\r\n SwaggerUI \u00e9 uma ferramenta que analisa uma defini\u00e7\u00e3o de API para gerar documenta\u00e7\u00e3o. SwaggerUI tem um editor baseado no navegador (mostrado abaixo). Voc\u00ea pode experimentar o editor SwaggerUI aqui: https:\/\/editor.swagger.io\/<\/p>\r\n No lado esquerdo, a especifica\u00e7\u00e3o OpenAPI no formato YAML \u00e9 vis\u00edvel. Sempre que voc\u00ea fizer altera\u00e7\u00f5es na especifica\u00e7\u00e3o, essas altera\u00e7\u00f5es geram nova documenta\u00e7\u00e3o no painel do lado direito. O painel do lado direito \u00e9 o documento Swagger gerado diretamente a partir da especifica\u00e7\u00e3o OpenAPI para o Petstore (painel do lado esquerdo). Por exemplo, mudar a descri\u00e7\u00e3o de um caminho faz com que o documento Swagger atualize com as novas altera\u00e7\u00f5es.<\/p>\r\n Se voc\u00ea olhar a especifica\u00e7\u00e3o do Swagger OpenAPI<\/a> \u00e0 esquerda, voc\u00ea ver\u00e1 todas as se\u00e7\u00f5es descritas neste artigo do blog, incluindo openapi, informa\u00e7\u00f5es, servidores, caminhos, componentes, tags, etc.<\/p>\r\n Swagger gera um erro quando voc\u00ea se desvia da estrutura do OpenAPI ou inserir algo inv\u00e1lido. A manipula\u00e7\u00e3o de erros do Swagger refor\u00e7a o conceito que voc\u00ea deve aderir ao formato OpenAPI para exibir corretamente. Quando voc\u00ea se familiarizar com o Swagger Petstore, voc\u00ea pode colar a especifica\u00e7\u00e3o para outra API no Swagger Editor para ver como suas informa\u00e7\u00f5es s\u00e3o exibidas na SwaggerUI.<\/p>\r\n Em resumo, O Swagger Editor \u00e9 uma \u00f3tima maneira de se familiarizar com como escrever defini\u00e7\u00f5es de API e como ferramentas analisam a especifica\u00e7\u00e3o para gerar documenta\u00e7\u00e3o.<\/p>\r\n Para uma documenta\u00e7\u00e3o mais aprofundada sobre o padr\u00e3o OpenAPI, leia a documenta\u00e7\u00e3o oficial do SmartBear para o OpenAPI: https:\/\/swagger.io\/specification\/. Al\u00e9m disso, confira nosso guia para lan\u00e7ar API p\u00fablica<\/a><\/em><\/strong><\/p>\r\n Pronto para levar sua documenta\u00e7\u00e3o de API para o pr\u00f3ximo n\u00edvel? Reserve uma demonstra\u00e7\u00e3o com o Document360 hoje!<\/p>\r\nReserve uma demonstra\u00e7\u00e3o<\/a><\/div>\r\n Uma API aberta (tamb\u00e9m conhecida como uma API p\u00fablica) \u00e9 uma interface de programa\u00e7\u00e3o de aplicativos publicamente dispon\u00edvel que permite que desenvolvedores acessem um aplicativo de software propriet\u00e1rio ou um servi\u00e7o on-line de forma program\u00e1tica.<\/p>\r\n<\/div>\r\n<\/li>\r\n\t Uma API aberta tem restri\u00e7\u00f5es de acesso porque est\u00e1 aberta ao p\u00fablico e pode ser chamada de qualquer lugar na internet. Uma API fechada, tamb\u00e9m conhecida como uma API privada, por outro lado, n\u00e3o est\u00e1 dispon\u00edvel publicamente na internet.<\/p>\r\n<\/div>\r\n<\/li>\r\n\t O OpenAPI Standard (OAS), anteriormente conhecido como a Especifica\u00e7\u00e3o Swagger, \u00e9 um formato para descri\u00e7\u00e3o, produ\u00e7\u00e3o, consumo e visualiza\u00e7\u00e3o de RESTful web services. O padr\u00e3o da API REST descreve a estrutura e a sintaxe.<\/p>\r\n<\/div>\r\n<\/li>\r\n<\/ul>\r\n<\/div>\r\n<\/div>\r\n<\/div>\r\n\r\n\t
\r\n\t
Hist\u00f3ria da OpenAPI<\/h2>\r\n
Por que o OpenAPI \u00e9 um padr\u00e3o popular?<\/h2>\r\n
Como o OpenAPI define uma API?<\/h2>\r\n
Formato do OpenAPI<\/h2>\r\n
![\"t\u00edtulo](\"https:\/\/document360.com\/wp-content\/uploads\/2022\/12\/title_of_specification.png\")
<\/p>\r\nTipos de Dados<\/h2>\r\n
Estrutura<\/h2>\r\n
\r\n\t
![\"Modelo](\"https:\/\/document360.com\/wp-content\/uploads\/2022\/12\/API_template_with_structure.png\")
<\/p>\r\n\r\n\t
Schemas<\/h2>\r\n
\r\nEsta se\u00e7\u00e3o \u00e9 um gloss\u00e1rio r\u00e1pido para quando o leitor precisa ver os esquemas gerais no contexto mais amplo da API (n\u00e3o a sua utiliza\u00e7\u00e3o em opera\u00e7\u00f5es espec\u00edficas). Esquemas s\u00e3o objetos que cont\u00eam propriedades\/metadados.
\r\nA se\u00e7\u00e3o de esquemas seguintes para a Swagger Petstore apresenta esquemas espec\u00edficos. Order<\/strong> \u00e9 um esquema que representa uma ordem feita para um animal de estima\u00e7\u00e3o na Swagger Petstore. Cada pedido tem seus metadados, incluindo seu Id, a data que foi enviada e o status do pedido<\/strong>.<\/p>\r\n![\"esquemas](\"https:\/\/document360.com\/wp-content\/uploads\/2022\/12\/spec_wide_schemas.png\")
<\/p>\r\nPontos fortes do OpenAPI<\/h2>\r\n
\r\n\t
Fraquezas do OpenAPI<\/h2>\r\n
Menos \u00fatil para design e planejamento da API<\/h3>\r\n
N\u00e3o Hier\u00e1rquica<\/h3>\r\n
\r\n\t
N\u00e3o suporta a heran\u00e7a do modelo de dados<\/h2>\r\n
N\u00e3o \u00e9 uma ferramenta “visual”<\/h3>\r\n
Falta de suporte para outras arquiteturas<\/h3>\r\n
Exemplo da OpenAPI – Swagger Petstore<\/h2>\r\n
![\"Swagger](\"https:\/\/document360.com\/wp-content\/uploads\/2022\/12\/Swagger_UI_examples.png\")
<\/p>\r\nLeitura adicional<\/h2>\r\n
\r\n<\/em><\/strong><\/p>\r\n![\"Documento360\"](\"https:\/\/document360.com\/wp-content\/themes\/document360\/images\/blog-call-to-action.png\")
<\/div>\r\n<\/div>\r\nPerguntas Frequentes<\/h2>\r\n
\r\n\t
O que \u00e9 um OpenAPI? <\/a><\/h3>\r\n
Qual \u00e9 a diferen\u00e7a entre a API privada e aberta? <\/a><\/h3>\r\n
O que \u00e9 OpenAPI e API REST? <\/a><\/h3>\r\n