Releases: RESTEDClient/RESTED
2.5.0
Release of 2.5.0
New Features
- #219 Make syntax highlighting size limit configurable (Thanks @ChiefOfGxBxL!)
Improvements
- #218 Enforce minimum value of zero on max history size (Thanks @ChiefOfGxBxL!)
- #222 Re-add CI to workflow
- #223 Add security scanning
- #224 Add dependabot security updates
- Update a few dependencies
Contributors
Assets 7
2.4.0
Release of 2.4.0
Improvements
- #209 Install cross-env for environment variables in start scripts (Thanks @ChiefOfGxBxL!)
- #210 Options modal UI updates (Thanks @ChiefOfGxBxL!)
- #211 UI improvements to Collections list (Thanks @ChiefOfGxBxL!)
Contributors
Assets 7
2.3.1
2.3.0
2.2.1
2.2.0
2.1.1
2.1.0
Release of 2.1.0
This version has a few interesting features, so I decided to to sit down and write a few words. From now on, I'll write a little text here whenever anything interesting is released.
2.1.0 includes a pretty big change that is only possible thanks to the WebExtensions API. In version 2.0, we changed from using XHR to the fetch API, which was great for the developer experience of the extensions (XHR makes me feel nauseous). However, there were uninteded consequences of this - suddenly a ton of response headers were missing in Chrome!
It turns out, even though we are in a WebExtension context with the <all_urls> host permission set, Chrome requires fetch to have cross origin headers set on responses. That is to say - it works and you get your data, but the server needs to specify which headers should be exposed in a comma separated header called Access-Control-Expose-Headers. Yikes!
So we went back to the drawing board, and came up with a solution, which turned out to be pretty great. Now we are intercepting all requests sent from the RESTED tab and reading headers from that instead. Why does this matter? Because doing it that way we have access to all the headers, regardless of CORS!
And another cool feature of intercepting requests - we are no longer constrained by a security feature of the web, making redirects completely transparent. This means we can show redirects now!
Another thing we worked on this release was a rework of how request bodies worked. Previously we defaulted to using multipart forms, which are not that common outside of file uploads, and didn't really offer any alternative outside of DIY. Hell, even REST API's most common format, JSON, was not well supported.
In this release, we are shipping what I call "body presets", which is a noticable improvement. JSON is now a first class citizen, alongside its friends multipart and x-www-urlencoded. It will be much easier to use formats like JSON now, because you can use the same form that you've been able to use in the past, except now it will send JSON!
Hope you like this release, and hope you enjoyed this little writeup! From now on, I'll try to write a little blurb every release, and a longer one like this if there is anything interesting to note.
Featues
- #106 Adds request body presets
- #103 Default request body is now json
- #88 The user's previously selected body preset is now presisted across reloads for new requests
- #78 Changes the request body to be expanded by default
- #84 Adds support for viewing headers of server-initiated redirects
Fixes
2.1.0-rc.3
Fix issues issue with HSTS upgrade redirects in firefox
2.1.0-rc.2
Bump version to 2.1.0