Blog

- March 27, 2017

Now with more expressivity than before, Restlet Studio is the easiest and most accurate way to design your APIs, and export them to OAS / Swagger with absolute precision. These improvements are all included in your automatically generated and hosted API documentation.

Restlet Studio is growing to meet the demands of its community of API designers!

Restlet Studio was the first visual API designer to support multiple API definition languages (RAML and OAS). Since then, it has been adopted by teams of all sizes working on a variety of projects, and used to design and document APIs, as well as to export OAS or RAML definitions that are then used in API gateways like AWS API Gateway, Apigee Edge, TIBCO Mashery and other tools.

We are also increasingly seeing Restlet Studio used in combination with Restlet Client because the pair offer an approach to automated testing based on an API-first workflow. We have been listening to requests from our users who have found missing elements in Studio and are happy to announce that Studio has now reached full maturity in terms of expressivity!

For those joining for the first time, we’ve created a new video overview of Studio that covers the basics and advantages it offers.

Extensive support for OAS 2

Those interested in crafting OAS / Swagger definitions will be glad to hear that we are very close to full compatibility with the Open API Specification version 2.0. For example, if you’re using OAS in an API tool chain that requires you to modify the operationId OAS attribute, we’ve got you covered. Those looking to group their OAS operations by tag will now also find everything they need.

If you need to specify metadata on your model attributes, such as enumerations, formats, and even examples, we’ve got you covered as well!

Advanced content negotiation and hypermedia

Studio is now the only visual API designer that supports advanced content negotiation. This is one of the improvements we have made to let you define APIs that, for the same operation, will respond with a different response body depending on the requested media type. For example, say you have a GET /contact/{contactId} operation that returns a Contact. You are now able to specify that if the request accepts application/json, then a JSON representation of the Contact will be returned, but if the request asks for image/jpeg or image/png, an image representation of the Contact will be returned. Neat!

List of expressivity improvements

  • Data types
    • File types
    • Date types
    • Arrays of arrays
    • Validation attributes (enums, format, pattern, min/max, …)
    • Data type examples
    • Inline data types
  •  Operations
    • Operation-level media types
    • Response headers
    • Request and response bodies that vary according to the media type (for content negotiation / hypermedia)
    • Request & response examples
    • OAS operationId
    • OAS tags
  • General
    • Contact information
    • Global media types
    • OAuth 2.0 Authorization Grants

Upcoming improvements

The final missing piece for Studio is more detailed security parameters. We’ll be making another release shortly that will provide full OAuth 2.0 capabilities, and the ability to specify security this is applied globally, as well as overriding security on specific operations.