<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>Forem: Sébastien Charrier</title>
    <description>The latest articles on Forem by Sébastien Charrier (@scharrier).</description>
    <link>https://forem.com/scharrier</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F583932%2F7a081615-2cac-422e-8ed6-86af97d3a833.jpeg</url>
      <title>Forem: Sébastien Charrier</title>
      <link>https://forem.com/scharrier</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://forem.com/feed/scharrier"/>
    <language>en</language>
    <item>
      <title>Two OpenAPI 3.1 changes we love</title>
      <dc:creator>Sébastien Charrier</dc:creator>
      <pubDate>Tue, 23 Feb 2021 08:10:49 +0000</pubDate>
      <link>https://forem.com/bump/two-openapi-3-1-changes-we-love-1ig2</link>
      <guid>https://forem.com/bump/two-openapi-3-1-changes-we-love-1ig2</guid>
      <description>&lt;p&gt;Last week, version 3.1 of OpenAPI has officially landed after several beta and release candidates. This is a great news for the REST API community, as some important changes are coming with this version. Congrats to all the team behind this huge step forward!&lt;/p&gt;

&lt;p&gt;Here are two major changes we loved so much at Bump that we have already released their support.&lt;/p&gt;

&lt;h2&gt;
  
  
  Webhooks support
&lt;/h2&gt;

&lt;p&gt;This is one of the most important changes in 3.1: you can now describe webhooks provided by your API in your OpenAPI specification, the same way you describe your API paths.&lt;/p&gt;

&lt;p&gt;If you don't know what a webhook is, you may want to &lt;a href="https://codeburst.io/what-are-webhooks-b04ec2bf9ca2"&gt;read this article&lt;/a&gt; before going any further.&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;Webhooks provide a mechanism where by a server-side application can notify a client-side application when a new event (that the client-side application might be interested in) has occurred on the server.&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;Here is an example of how you describe a webhook with OpenAPI 3.1:&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;webhooks:
  newPet:
    post:
      requestBody:
        description: Information about a new pet in the system
        content:
          application/json:
            schema:
              $ref: "#/components/schemas/Pet"
      responses:
        "200":
          description: Return a 200 status to indicate that the data was received successfully
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



&lt;p&gt;I'm glad to announce that these &lt;a href="https://headwayapp.co/bump-changelog/hello-openapi-webhooks-186095"&gt;OpenAPI webhooks are already supported by Bump&lt;/a&gt; as first class citizen: we show them in your documentation and analyze them when generating the automatic changelog.&lt;/p&gt;

&lt;p&gt;You have nothing more to do, just deploy your first specification with webhooks and you'll see the magic happen. &lt;a href="https://bump.sh/doc/webhook-example"&gt;See a live example&lt;/a&gt;&lt;/p&gt;

&lt;h2&gt;
  
  
  Better $ref pointers
&lt;/h2&gt;

&lt;p&gt;I really love this one, as it solves a nightmare for those who have experienced splitting their OpenAPI file into reusable components.&lt;/p&gt;

&lt;p&gt;Until now, as described in the specification, &lt;code&gt;$ref&lt;/code&gt; pointers were fully replaced by what they were pointing to when resolving an OpenAPI specification. This means that any sibling of the &lt;code&gt;$ref&lt;/code&gt; was removed. For instance:&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;property:
  $ref: #/components/pointer
  required:
    - hello
components:
  pointer:
    hello: world
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



&lt;p&gt;Was resolved as:&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;property:
  hello: world
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



&lt;p&gt;As you may see, the &lt;code&gt;required&lt;/code&gt; key alongside &lt;code&gt;$ref&lt;/code&gt; was removed. This was particularly annoying when trying to reuse a model in different contexts, like in this situation where you want to specify some required attributes.&lt;/p&gt;

&lt;p&gt;The good news is that as a part of its JSON Schema compatibility migration, OpenAPI 3.1 allows us to merge these siblings with the resolved &lt;code&gt;$ref&lt;/code&gt; ones. The previous example now results into this:&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;property:
  hello: world
  required:
    - hello
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



&lt;p&gt;This change will simplify some specifications, and probably remove a lot of code duplication. And yes, this is supported by Bump as of now.&lt;/p&gt;

&lt;h2&gt;
  
  
  What about other 3.1 changes?
&lt;/h2&gt;

&lt;p&gt;There are &lt;a href="https://github.com/OAI/OpenAPI-Specification/releases/tag/3.1.0"&gt;many other changes&lt;/a&gt; in this new version of the specification. In our effort to offer the best possible OpenAPI experience, we will strive to support them all.&lt;/p&gt;

&lt;p&gt;Have any comment or question about OpenAPI 3.1? &lt;a href="//mailto:hello@bump.sh"&gt;Ping us anytime&lt;/a&gt;, we will always answer.&lt;/p&gt;

</description>
      <category>api</category>
      <category>openapi</category>
      <category>apidesign</category>
    </item>
  </channel>
</rss>
