Skip to content
Closed
Changes from 13 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
36 changes: 35 additions & 1 deletion spec.md
Original file line number Diff line number Diff line change
Expand Up @@ -841,11 +841,45 @@ For success responses, the following fields are defined:
| --- | --- | --- |
| dashboard_url | string | The URL of a web-based management user interface for the Service Instance; we refer to this as a service dashboard. The URL MUST contain enough information for the dashboard to identify the resource being accessed (`9189kdfsk0vfnku` in the example below). Note: a Service Broker that wishes to return `dashboard_url` for a Service Instance MUST return it with the initial response to the provision request, even if the service is provisioned asynchronously. If present, MUST be a non-empty string. |
| operation | string | For asynchronous responses, Service Brokers MAY return an identifier representing the operation. The value of this field MUST be provided by the Platform with requests to the [Last Operation](#polling-last-operation) endpoint in a percent-encoded query parameter. If present, MUST be a non-empty string. |
| extension_apis | array-of-objects | For extensions to the Service Broker API on a per Service Instance basis, Service Brokers MAY return one or more objects that describe additional API endpoints via an OpenAPI document. See [Extension APIs Object](#extension-apis-object) for more information. |

##### Extension APIs Object

The `extension_apis` object MAY be used to describe any additional endpoint
needed related to a Service Instance. An example of this could be lifecycle
management, (e.g. "Day Two Operations"), like Backup, Restore, Stop, Start,
Restart and Pause.

The Service Instance provisioning request will return a URI to an OpenAPI 3.0+
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

perhaps s/request will return/response will include/ since its not the request that contains the data.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To me this reads that there's only one object returned: I was thinking that there is an object:
extension_api {
discovery_url string
credentials credType
adheres_to string
}
and:
extension_apis []extension_api

So, there's the struct that rerepresents a single discovery_url (with creds) and there can be an array of them. Somehow reading this however, I think there's only one.

document that the Platform can use to determine the new endpoint(s),
parameter(s), authentication mechanism and server URL. The new APIs are
extensions to the Open Service Broker API. As such they are indended to be
invokved by the Platform on behalf of its clients.

Extension API endpoints MAY be executed on a remote server, however the OpenAPI
document MUST include the servers `url` so that the Platform will know how to
invoke the endpoint(s). If the server `context` parameter of the OpenAPI
document is set to localhost the Platform can assume the extension API endpoints
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

may want to backtick localhost

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we s/can assume/MUST assume/ ?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done. I think that makes sense. I can't think of a reason they wouldn't want to assume that.

are to be invoked using the Service Broker host and port.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't get this. If the description field is not "Service Broker Extensions Server", the platform uses the brokers host and port. Why need the URL be absolute in this case? Isn't it relative to the broker? What if the broker host/port don't match the URL?
It can be difficult for a broker to determine the right host name in this context. It would be easier for a broker to return the (absolute) path here.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're 100% right. I think I addressed this in the latest change.

| Response field | Type | Description |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/field/Field/

| --- | --- | --- |
| discovery_url | string | A URI pointing to a valid OpenAPI 3.0+ document describing the API extension(s) to the Service Instance including server location, endpoints, parameters and any other detail the platform needs for invocation. The location of the API extension endpoint(s) can be local to the Service Broker or on a remote server. MUST be a valid URI. The returned OpenAPI document MUST be in json format. See the [OpenAPI Specification](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md) for more information. |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you need to add a * and the * Fields with an asterisk are REQUIRED. sentence after the description of the fields.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup, I thought I did. Must've reverted. There now.

| credentials | object | A Service Broker MAY return authentication details for running any of the extension API calls, especially for those running on remote servers. If not present, the same authentication mechanism used for the normal Open Service Broker APIs MUST work for the new endpoint(s). If the Service Broker wants to use alternate methods of authentication, (e.g. on remote servers) it MUST provide details to that mechanism in the OpenAPI document, (e.g. an OAuth Flow Object), and the appropriate credential(s), (e.g. bearer token), as part of the `extensions_api` object. If credentials are present in an `extensions_api` object, the Platform will need to verify the authentication method from the OpenAPI document. |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/as part of the extensions_api object/within this credentials field/ I think

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

field? object? I put field for now.

| adheres_to | string | A URI refering to a specification detailing the implementation guidelines for the OpenAPI document hosted at the `discovery_url`. While this property is a URI, there is no requirement for there to be an actual server listening at that endpoint. This value is meant to provide a unique identifier representing the set of extensions APIs supported. If present, MUST be a valid URI. |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The semantics of this column could be clarified a little bit - what is the advantage of specifying a URI that points to a location where no server is running?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I don't follow. Which part are you referencing?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While this property is a URI, there is no requirement for there to be an actual server listening at that endpoint. and If present, MUST be a valid URI. confuse me a little. If it's not required to be a server, why do we enforce it to be a URI?

Am I write in thinking that this field is going to be used to allow clients to spot "common" operations that they could do, say, in bulk across multiple service instances?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Often people push for unique IDs to be URIs so that they avoid strings that too simplistic - like "backup". By making it a URI its trying to force people to namespace things by including some domain name in the URI.

While I've heard bulk ops as one reason for this, to me the bigger reason is that a platform (or its UI) can know when it comes across some actions that it knows about and may want to do some special processing for. E.g. perhaps it has a dedicated UI for them. W/o some well defined URI to say "yes, these are the set of ops that's been defined by spec xxx" the platform can't really be sure what those ops do. Checking (strcmp) the names of the ops alone doesn't really guarantee anything.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As per Paul's suggestion I will add some text here about what the Platform can do with this information. Should clear this up, (mildly).



```
{
"dashboard_url": "http://example-dashboard.example.com/9189kdfsk0vfnku",
"operation": "task_10"
"operation": "task_10",
"extension_apis":[{
"discovery_url": "http://example-openapi-doc.example.com/extensions",
"credentials":[{
"tokenURL": "https://example.com/api/oauth/token"
}],
"adheres_to": "http://example-specification.example.com"
}]
}
```

Expand Down