OpenAPITools
Deleted or renamed properties are marked as backwards compatible
Hello folks,
i am testing your library as a maven plugin with version: 'org.openapitools.openapidiff:openapi-diff-core:2.1.0-beta.11' and discovered that the following changes do not result in failure due to backwards incompatibility even though they should, right?
- Removing properties from schemas
- Renaming properties
Hello folks, mostly all incompatibility rules are collected in BackwardIncompatibleProp. As you can see it has:
- RESPONSE_REQUIRED_DECREASED
- REQUEST_BODY_REQUIRED_INCREASED.
Seems, author decided to only treat new required props on request and missing required props on response as incompatible. So it depends on the point of view. From my perspective - removing any payload property is a breaking change as API consumer can depend on it.
So the openapi-diff as a library should be smart enough to allow to configure of what is considered compatible change, and what is not. This behavior is configurable through the config file, but frankly speaking, it does not cover all possible cases. Good point to extend and review all the rules.
Is there an update on this issue? I am also facing the same issue where a compatibility break in terms of schema change in response doesn't mark the diff as incompatible. Below is the example -
Original Spec
openapi: "3.0.0"
info:
title: Sample API
version: "1.0.0"
paths:
/users:
get:
summary: Get all users
responses:
"200":
description: A list of users
content:
application/json:
schema:
type: array
items:
type: object
properties:
id:
type: string
name:
type: string
Updated spec
openapi: "3.0.0"
info:
title: Sample API
version: "2.0.0"
paths:
/users:
get:
summary: Get all users
responses:
"200":
description: A list of users
content:
application/json:
schema:
type: array
items:
type: object
properties:
id:
type: string
fullname: # Breaking change (renamed `name` → `fullname`)
type: string
This looks like a bug to me, but let me know if there is a configuration which would evaluate this diff as incompatible.
@nakulshukla08 there is an idea to solve this problem within the scope of discussion. But the first priority at the moment is to get 2.1.0 release happen.
Anyway, any contributions to discussion and related issues are appreciated, feel free to contribute.
