3 ms·

Unirest is the BYOC that I was hoping would get traction: https://github.com/kong?q=unirest https://github.com/kong?q=unirest I don't understand why each API n

by pbreit 6y ago

Unirest is the BYOC that I was hoping would get traction: https://github.com/kong?q=unirest https://github.com/kong?q=unirest I don't understand why each API needs it's own SDK. Or even why developers use SDKs instead of just calling the RESTful endpoints directly.

mmcdermott 6y ago
I understand both sides of it. The thing is that most code bases that aren't using an official SDK will tend to wrap the raw HTTP calls in something that performs the relevant operations anyway. A good SDK cuts out a few classes/functions that would have been written anyway. Of course, that assumes that the SDK exists and is good.
granos 6y ago
If the SDK in question is just a thin wrapper on REST then sure, it isn't providing very much value. But most of the SDKs I've used implement higher level logical operations -- things that require understanding the intent of the API/data model and how things are supposed to fit together. By being able to write my code against that higher level abstraction I'm able to save time and offload some of the responsibility for knowing how the pieces all fit together to the people who know that best. Ultimately my goal is not to make REST requests, it's to provide value to my customers, and the APIs I call are means to that end.
scottlamb 6y ago
I think the problem described in this article is more fundamental: these services don't have documented, stable APIs for clients to build on. Not HTTP APIs. Not libraries either. In some cases they go out of their way to prevent third parties from using whatever internal API their own apps use. [edit to add: to combat abuse/spam, or because they have ads, or as deliberate lock-in.] But to answer your question: when an API exists, why have an SDK? One reason is to provide strong typing (and everything that goes with it, like IDE auto completion). A very thin layer over the HTTP requests is enough to provide this. Eg, in one of my projects [1] I wrapped a HTTP API with Go calls like this: Method(ctx context.Context, req *MethodRequest) (*MethodResponse, error) where each method call corresponds to exactly one HTTP request. It handles deadlines, cancellation, HTTP error checking, and using Go's built-in json marshalling/unmarshalling on structs. That's about all I want in an SDK. The unirest project you linked doesn't seem to offer strong typing so I wouldn't use it (even if it weren't dead). [1] https://github.com/scottlamb/luxor https://github.com/scottlamb/luxor

by pbreit 6y ago

mmcdermott 6y ago

I understand both sides of it. The thing is that most code bases that aren't using an official SDK will tend to wrap the raw HTTP calls in something that performs the relevant operations anyway. A good SDK cuts out a few classes/functions that would have been written anyway. Of course, that assumes that the SDK exists and is good.

granos 6y ago

If the SDK in question is just a thin wrapper on REST then sure, it isn't providing very much value. But most of the SDKs I've used implement higher level logical operations -- things that require understanding the intent of the API/data model and how things are supposed to fit together. By being able to write my code against that higher level abstraction I'm able to save time and offload some of the responsibility for knowing how the pieces all fit together to the people who know that best. Ultimately my goal is not to make REST requests, it's to provide value to my customers, and the APIs I call are means to that end.

scottlamb 6y ago

I think the problem described in this article is more fundamental: these services don't have documented, stable APIs for clients to build on. Not HTTP APIs. Not libraries either. In some cases they go out of their way to prevent third parties from using whatever internal API their own apps use. [edit to add: to combat abuse/spam, or because they have ads, or as deliberate lock-in.] But to answer your question: when an API exists, why have an SDK? One reason is to provide strong typing (and everything that goes with it, like IDE auto completion). A very thin layer over the HTTP requests is enough to provide this. Eg, in one of my projects [1] I wrapped a HTTP API with Go calls like this: Method(ctx context.Context, req *MethodRequest) (*MethodResponse, error) where each method call corresponds to exactly one HTTP request. It handles deadlines, cancellation, HTTP error checking, and using Go's built-in json marshalling/unmarshalling on structs. That's about all I want in an SDK. The unirest project you linked doesn't seem to offer strong typing so I wouldn't use it (even if it weren't dead). [1] https://github.com/scottlamb/luxor https://github.com/scottlamb/luxor