1 min read

How to Make REST API on Swift Even Better. I'm Working On Vapor RestKit 2.0

I've started to work on a big update for Vapor RestKit. I've been using it for a while and noticed several shortcomings that were not noticeable at the stage of the initial design, both related to its internals and API.
How to Make REST API on Swift Even Better. I'm Working On Vapor RestKit  2.0
Photo by David McCumskay / Unsplash

I've started to work on a big update for Vapor RestKit.

I've been using it for a while and noticed several shortcomings that were not noticeable at the stage of the initial design, both related to its internals and API.

RestKit Was Finally Rewritten

The thing that was intended to save time accidentally turned the internals of RestKit into inheritance hell not leaving a chance to figure out what was going on there. To be honest, I didn't like it but never had time to rewrite it.

Not long ago I rewrote all the internals to make it much more simple and minimal and decided that it is a good start for Vapor RestKit 2.0

Declarative RestKit API Is Gonna Be Deprecated

The API is gonna be broken.

Vapor RestKit declarative API looked cool at first sight but in practice it
appeared to be too magical and not at all convenient as expected.

It's been cool to create CRUDs in just 6 lines of code, but not very flexible for making changes and combining with non-Vapor-RestKit methods.

This time, everything will be simple. (Hopefully)

RestKit API Is Gonna Be Simplified

I will deprecate declarative API and will allow setup routes just like it's done in plain Vapor. That will encourage combining existing backend implementation with blazing RestKit.

I will remove forced versionable API stuff as it's just odd.

Now I'm experimenting to make sorting and filtering queries setup more simple.

Also, I'm thinking of an improvement for eager loading queries for nested resources.

I like how it works now and I want to make it even better. A kind of lightweight alternative to what we have in GraphQL, but for REST.