Announcement: FRAPI 0.1 Released!

[Davey Shafik]

The below is taken from: http://getfrapi.com/release/91

After almost exactly 2 years since our first release, with many production sites under its belt, we are delighted to present not only the first numbered release of FRAPI (0.1.0), but also a glimpse at the future of FRAPI.

With this release, we have:

• Custom Mimetype support
• Re-written content-negotiation
• Support for mimetype params (e.g. application/json;charset=utf-8;version=1)
• Gzip compression
• Built-in documentation template with Markdown support using the Ace editor (available via the /route)
• Support for movable “custom” directories (FRAPI_CUSTOM_PATH environment variable), making it trivial to use as a submodule in your projects

Thanks to everybody for their support of this release, it’s been a long time coming, and we’re delighted to be pushing forward with FRAPI. In particular, we want to thank the participants of php|architect’sphp|tek 2012 Hackathon, sponsored by Engine Yard’s Orchestra PHP Cloud.

Grab the release from github now!

A note on stability: While we believe FRAPI to be quite stable (indeed, it’s used in many production environments), and every effort will be made to avoid backwards incompatible changes, we are not yet guaranteeing backwards compatibility. In cases where we cannot maintain backwards compatibility we will endeavor to provide as seamless a transition as possible.

With that said, we want to take this opportunity to take a look at the (possible) future of FRAPI, starting with the 0.2 release, and beyond.

Project Structure

Due to the fact we recommend that the FRAPI admin not be installed on your production systems, as well as the use of the (file size wise) heavy weight Zend Framework used to build it, we are considering splitting the admin, and the API code itself into two separate repositories. This will ensure speedy deployment on cloud architectures where servers provisioning speed can effect the performance of your APIs.

User Interface & User Experience (UI/UX)

We are currently undertaking a full review of the UI and UX of the FRAPI admin. The initial review can be seen on our wiki and additionally we are working on a UI mockup, which can be seen here. This includes a full rebranding of FRAPI so that we can better represent the quality of the project as we believe it to be.

New Features & Improvements

We have a number of new features we wish to implement, examples include:

• Support for RFC 6570 URI Templates for specifying routes (and potentially other uses)
  • This might be a backwards incompatible change, however currently we believe that it should be possible to support and automatically migrate existing routes as the formats do not clash.
• Full support for OAuth
• A caching mechanism intended for use within your APIs, with support for etags
• Support for conforming to HATEOS
• Support for accurate statistics
• Support for rate-limiting

Additionally, we hope to improve:

• The configuration mechanism, moving away from XML.
• Further improvements to generated documentation, including inline API console for testing
• More unit tests!
• Greater control over the execution flow from within your API implementation

We will continue to make FRAPI the best option for implementing great APIs.

One final effort we will be embarking on, is to educate the community on best practices; including user experience  (UX), HATEOS and correct use of HTTP.

We hope you will join us in continuing to build FRAPI towards a great 1.0 release. Go ahead and fork us, and claim an open issue to work on.