Generate HTTP REST requests behind the scenes

Language Design
1

Since microservices is the silver bullet of today (or yesterday?) we have a lot of REST requests going forth and back between these services, often with libraries like Ktor. We define routes and check if they match the path and HTTP verb. But why do we need this hassle? Why do the developer need to care about HTTP and REST at all? Why can’t I just mark a class as a “resource” (or whatever we will call it), and then be able to use its methods from outside.

I have been asking about statically typed REST APIs before. A huge problem with REST APIs is that they are dynamically typed. I can send a String when a Boolean is required. The REST API would have to return a HTTP 4xx code for illegal input (I don’t even remember these codes). Why can’t we have static type checking on these APIs?

If we on the backend implement

@Resource("/companies")    
class CompanyResource {

    fun getBankruptCompanies(from: Date, to: Date): List<Company> {
       //blabla
       return bankruptCompanies;
    }

}

When I develop the front-end, I want to be able to write companyResource, then type a dot and get suggested getBankrupCompanies with from and to as parameters. I don’t want to communicate with backend-developers or go to Swagger to see what to call and which types it expects. I don’t want to care about HTTP or REST or 404, 406 or any other HTTP code that I don’t even remember. I just want to interact with the backend or other services as I would interact within the same service.

So the question is: Why not make this part of the language? If something is marked as a resource, the call gets executed behind the scenes, and the types are statically validated. Common types will be returned. On the frontend we would have the Company-type available and use it directly instead of parsing JSON and all that stuff. Just let things happen behind the scenes.

A call to companyResource.getBankruptCompanies(fromDate, toDate) could be translated to something like
GET /v10/companies/bankruptCompanies/2020-12-01T15:30:00Z/2020-12-20T15:30:00Z.
The developer would be super happy by not having to think about HTTP and all these error codes. Error codes could be translated to exceptions. Then when front-end (or another service) receives a 404, that is translate to the appropriate Exception.

What do you think?

3 Likes
2

There’s a few different ideas here.

It sounds like you really want some RPC or RMI library. Or maybe your use case would be solved with plain old serialization? You could check out gRPC (which recently got Google support for Kotlin). There are many other libraries and tools that solve similar cases like this (e.x. Protobuf).

Another point I should make is that you shouldn’t hide remote work as if it’s a normal method call. Suspending functions can solve this in Kotlin.

Lastly, you ask

This should not be part of the language. What you’re describing could be done with a library–in fact, I’d bet there are several libraries that do what you want. I’m on mobile so I won’t copy any examples right now.

4 Likes
3

You are absolutelly right. This is the way it should be.

Even simplier than that - there should be an interface and its implementation, a client gets an interface from a service provider that returns dynamic proxy, which translates the call to the service method as a REST call to a backend server sending the names of the service, the method and simple parameters via URL. In case of complex parameters they are sent in body as JSON. The server then receives the call and translates it to local implementation, then the response goes back similarily.

It cannot be done now, because Kotlin lacks things like dynamic proxies, reflection and simple JSON serialization (without a need to use any annotations), at least in its JavaScript part, but hopefully it will be supported in the future.

Now you should create your own framework to implement this. I’m doing this in my project now.

1 Like
4

@vk Can you open-source it please? I think you know this stuff slightly better than me… REST and HTTP and all this network things have never been my friends…

1 Like