Provide library containing only types

[SchulteDev]

Provide a dependency containing only types

twilio-java is an "all-in" library. Using it, I can send SMS, generating TwiML etc.

Feature request Please provide a dependency, which covers only the types, for example Message.

Reaons

I want to develop an AWS Java lambda, which shall act as Twilio message webhook. Adding twilio-java as a dependency would increase the size of the final jar by factor 2.

[thinkingserious]

Hello @SchulteMarkus,

We don't currently have any plans to refactor our helper libraries in this way.

For your particular use case, I would query the API directly with your favorite HTTP client. Twilio SendGrid has a simple generic stand-alone HTTP client (it's a thin wrapper around org.apache.httpcomponents) that may be useful for this scenario.

I will leave this ticket open so that our community can weigh in with further thoughts.

With best regards,

Elmer

[virtual-machinist]

One way this issue could become irrelevant if there were any OpenAPI specs for the endpoints, requests and responses (is there any?). There are many ways to generate code from that.

If Twilio were to publish such a thing, I as a developer could roll my own minimalistic client and stay reasonably up to date by regenerating code from the published models.

[childish-sambino]

@virtual-machinist There is a spec used by twilio-cli here: https://github.com/twilio/twilio-cli-core/tree/master/src/services/twilio-api

It just hasn't been moved to its own repo yet. And it's not entirely correct (post params need some work).

[virtual-machinist]

@childish-sambino that's great news, actually. While the human readable reference is one of the best I've come across so far, published api-docs can enable using tools like swagger-codegen to write specialized lightweight clients with less effort. This should definitely be in a separate repo, perhaps even a separate webpage with Swagger UI.

[jimm-porch]

Now that this issue is a couple years old, I'm wondering if the Twilio Java team is still against this idea?

At Porch we have found this pattern to be very helpful. We have a mix of backend JVM stacks (Scala, Kotlin, and legacy Java), but they all use Jackson-annotated classes to describe the data model.

Most of the variation exists in the clients, which want to use different effect types (Scala Future vs. Kotlin IO, etc). But the data model can usually be shared by these different clients just fine.

The current Twilio SDK is using a version of Jackson which is incompatible with our core stack, and so we're effectively blocked from upgrading beyond a certain version. I am experimenting with sending SMS using our own in-house Scala client, and it bypasses the Twilio client but still uses the Message class and RestException classes to parse the response.

If those data types were in a separate small JAR, decoupled from the client, then we would be able to continue using those official classes but without worrying about classpath incompatibilities from the client itself.

Unfortunately, to truly separate them would require a bit of work because the data types are not just pure data structures. They are coupled together with static functions that provide access to the client/fetching classes, for example we find these (and many many others) in Message.java

    public static MessageCreator creator(final com.twilio.type.PhoneNumber to,
                                         final String messagingServiceSid,
                                         final List<URI> mediaUrl) {
        return new MessageCreator(to, messagingServiceSid, mediaUrl);
    }

    public static MessageDeleter deleter(final String pathAccountSid,
                                         final String pathSid) {
        return new MessageDeleter(pathAccountSid, pathSid);
    }

    public static MessageFetcher fetcher(final String pathAccountSid,
                                         final String pathSid) {
        return new MessageFetcher(pathAccountSid, pathSid);
    }

    // etc

In my case, if we proceed with my experiment we may have to just duplicate the data types in our own codebase but without all the client side-effecting functions.