- Add binding rotation fields to the spec and guidance on how to use the expiration fields for service binding
- Remove ambiguity on provisioning status code and clarify 200 status with consistent language for depraction
- Add context object to the response of fetching a service instance and turn into a non-requirement for service instances
- Rename context to attributes and update openapi files and the spec with an example
- Moved attributes to metadata and returns the metadata on fetch
- Add guidance for orphan mitigation
- Reconcile openapi and swagger files to match and generate identical clients and servers
- Add guidance for remembering the state of service instance and service binding operations
- Add guidance to handle 500 errors from Service Instance update
- Add guidance to handle requests with invalid data
- Allow Service Brokers to indicate if a Service Instance is still usable after a failed update or deprovisioning and if an update can be repeated
- Specify that Platforms SHOULD NOT reuse IDs
- Allow the platform to supply Service ID and Plan ID as hints when retrieving a service binding or a service instance
- Add CF and K8s annotations to the profile document
- Add support for ETag and If-Modified-Since headers
- Clarify the response code when Platform does not provide the required API version header
- Service Instances can be labelled with information defined by the Service Broker
- Add expiration date and time for bindings
2019-06-11
- Added a delay to polling response for Service Instance and Service Binding last operations.
- Added a Service Offering specific async polling timeout.
- Allow a Service Instance context to be updated and add org name, space name, and instance names.
- Added list of endpoints to create Service Binding response body.
- Added mechanism for orphan mitigation.
- Allow brokers to return 200 for no-op update Service Instance requests.
- Allow brokers to not return parameters when returning a Service Instance or Service Binding.
- Add plan_updateable field to the Service Plan object.
- Clarify what happens when deleting during a provision/bind request.
- Restrict Operation strings to 10,000 chartacters in the response body for provisioning or deprovisioning a Service Instance, and binding or unbinding a Service Binding.
- Remove character restrictions on names of Service Offerings, and Service Plans.
- Allow empty descriptions in the response body for getting the last operations of Service Instances, and Service Bindings.
- Clarify broker behavior expected when deprovisioning while a provision request is in progress and unbinding while an unbind request is in progress.
- Clarify broker behavior when a provision request is received during a provision request for the same instance or when a binding request is received during a binding request for the same binding.
- Added maintenance info support to Service Plans.
- Added request identity header.
2018-07-24
- Added GET endpoints for fetching a Service Instance and Service Binding
- Added support for asynchronous Service Bindings (PR) and a new last operation endpoint for Service Bindings endpoint
- Added clarity around concurrent updates (PR)
- Added clarity on how Platform's can clean up after a failed provision or bind (PR)
- Added Opaque Bearer Tokens to the Platform to Service Broker Authentication section (PR)
- Provided guidance for CLI-friendly names (PR)
- Allow for uppercase characters in Service and Service Plan names (PR)
- Clarify that extra fields in requests and responses are allowed (PR)
- Allow an updated
dashboard_url
to be provided when updating a Service Instance (PR) - Added an OpenAPI 2.0 implementation
- Allow for periods in name fields (PR)
- Removed the need for Platforms to perform orphan mitigation when receiving an
HTTP 408
response code (PR) - Moved the
dashboard_client
field to Cloud Foundry Catalog Extensions - Added a compatibility matrix describing which optional features in the specification are supported by different Platforms
- Added clarity for returning Service Binding information via the GET endpoints (PR)
- Added guidance for supported string lengths (PR)
- Clarified that the
plan_updateable
field affects modifying the Service Plan, not parameters (PR) - Clarified which Service Plan ID to use for polling the last operation endpoint after an update (PR)
- Clarified Platform behaviour when a dashboard URL is not returned (PR)
- Fixed an incompatible change introduced in v2.12 (PR)
- Added clarity around the state of resources after a failure (PR)
- Added Content Type guidelines
2017-09-19
- Added
schemas
field to services in the catalog that brokers can use to declare the configuration parameters their service accepts for creating a service instance, updating a service instance and creating a service binding. - Added
context
field to request body for creating a service binding. - Added warning text about using characters outside of the "Unreserved Characters" set in IDs.
- Added information about
volume_mounts
objects. instance_id
andbinding_id
MUST be globally unique non-empty strings.- Allow non-BasicAuth authentication mechanisms.
- Added a Getting Started page including sample service brokers.
- Define what a CLI-friendly string is.
- Add service/plan metadata conventions.
- Add originating identity HTTP header.
2017-06-13
- Added
context
field to request body for provisioning a service instance (PUT /v2/service_instances/:instance_id
) and updating a service instance (PATCH /v2/service_instances/:instance_id
). Also added the profile.md file describing RECOMMENDED usage patterns for environment-specific extensions and variations.context
will replace theorganization_guid
andspace_guid
request fields in future versions of the specification. In the interim, both SHOULD be used to ensure interoperability with old and new implementations. - The specification now uses RFC2119 keywords to make it clearer when things are REQUIRED rather than OPTIONAL or RECOMMENDED.
- Request and response parameters of type string, if present, MUST be a non-empty string.
- Cleaned up text around status codes in responses, clarifying when they MUST be returned.
- Added clarity around the
app_guid
request field. - Clarified the semantics of
plan_id
andparameters
fields in the updating a service instance request body. - Clarified the default value of the
plan_updateable
field. - Clarified when
route_service_url
is REQUIRED and when brokers can return extra data in bindings.
2016-11-15
- Added field
bindable
to plan objects in /v2/catalog response. This allows services to have both bindable and non-bindable plans.
2016-08-01
- Service bind responses now include an optional field called
volume_mounts
. Backward incompatible changes tovolume_mounts
field in service bind response from experimental 2.9 format to final format.
2016-06-14
-
last_operation
endpoint now supportsservice_id
andplan_id
as request parameters. -
A new field
operation
may now be returned by brokers in asynchronous responses for Provision, Update, Deprovision. This field enables brokers to provide an internal identifier for the operation that clients should provide back to the service broker when polling thelast_operation
endpoint.
2015-11-8
-
In support for Route Services, service broker may now return a
route_service_url
in the response for a create binding request. -
A broker must specify
requires: ["route_forwarding"]
in its catalog endpoint if it supports Route Services. -
Clients may now send a new field
bind_resource
with the bind request, under which the parameters required for the binding are found. This would include, for example,app_guid
for an app binding androute
for a route binding. For backwards compatibility,app_guid
will remain a top-level key in addition to being included in thebind_resource
.
2015-10-08
-
Added support for Asynchronous Operations. Brokers may now return a 202 Accepted in response to provision, update, or deprovision requests to indicate the requested operation is in progress.
-
The parameter
accepts_incomplete=true
must be passed by the broker client with requests for provision, update, or deprovision to indicate support for an asynchronous response. The broker can then choose to execute the request synchronously or asynchronously. -
Added support for querying
last_operation
status at a new endpoint:GET /v2/service_instances/:guid/last_operation
2015-07-23
-
app_guid
field is no longer guaranteed to be included with create service binding requests -
New field
service_id
is required with update service instance requests
2015-06-23
- Added support for Arbitrary Parameters: service-specific configuration parameters that can be included with provision, update and bind requests
2014-10-31
- Added support for broker clients to change the service plan for a specified service instance using new Update Service Instance endpoint
2014-04-23
- Added
dashboard_client
field to /v2/catalog to enable broker client to provision OAuth client for a service dashboard
2014-03-31
- Added field
free
for service plan in catalog endpoint
2013-12-27
- New field
app_guid
is required with bind requests