Latest Release: 04/24/19
Release Notes can be found here.

Upcoming breaking changes to API for workspace method configs

Geraldine_VdAuweraGeraldine_VdAuwera Cambridge, MAMember, Administrator, Broadie admin
edited August 2017 in FireCloud Announcements

This is a notification intended for anyone who uses the APIs to interact with FireCloud. If you don't know what that is, you don't need to worry about it. If you'd like to be notified of any future API changes by email, please join the new API users mailing list.

TL;DR: Changes will be made to the following endpoints in the next release (likely arriving on 23 August 2017) :

PUT /api/workspaces/{workspaceNamespace}/{workspaceName}/method_configs/{configNamespace}/{configName}
POST /api/workspaces/{workspaceNamespace}/{workspaceName}/method_configs/{configNamespace}/{configName}/rename

These endpoints create and edit method configurations that have been imported into a workspace. A diff of the Swagger description will be posted once the release is out. Read on below the fold for a more detailed description of how these endpoints' behaviours will change.


PUT

PUT /api/workspaces/{workspaceNamespace}/{workspaceName}/method_configs/{configNamespace}/{configName}

The behaviour of this endpoint used to be:

  1. Look for a method configuration at the location described in the URI and archive it.
  2. Place the method configuration in the JSON payload in the workspace described by the URI, at the namespace and name described in the JSON payload.

As well as flying in the face of REST principles (PUT should add a resource to the location in the URI, not remove it!), the implementation had a serious bug that would allow users to rename over an existing method configuration without archiving the old one. This would result in two method configurations with the same name in the same workspace, making the workspace uncloneable and the method configurations unlaunchable.

The behaviour of this endpoint is now:

  1. Place the method configuration in the JSON payload in the location described in the URI.

The location described in the payload must match the location in the URI, otherwise HTTP 400 Bad Request is returned. Any existing method configuration at that location will be overwritten.

If you're looking for something akin to the old behaviour, use this new endpoint:

POST /api/workspaces/{workspaceNamespace}/{workspaceName}/method_configs/{configNamespace}/{configName}

This behaves as follows:

  1. Look for a method configuration at the location described in the URI and archive it.
  2. Attempt to place the method configuration in the JSON payload in the workspace described by the URI, at the namespace and name described in the JSON payload.

If there already exists a method configuration at the new location, return HTTP 409 Conflict.

You can use this endpoint to edit both the contents of a method configuration and rename it, on the condition that no method configuration with that name already exists in the workspace.


POST

POST /api/workspaces/{workspaceNamespace}/{workspaceName}/method_configs/{configNamespace}/{configName}/rename

The behaviour of this endpoint has been extended to return HTTP 400 Bad Request if the workspace name and namespace inside the JSON payload don't match those in the URI. You can't rename method configurations across workspaces, so we were throwing away the workspace details in the JSON payload. Now we're enforcing they be identical to make that obvious.

Sign In or Register to comment.