The usual guideline for pluralized names (“Packages that provide most of their functionality in association with a new type”) doesn’t apply here, and I don’t think “RestClients” adds any clarity regarding the functionality of the package - if anything, it could mislead users into thinking it’s an instance of this guideline (that it works by creating a RestClient type).
I slightly prefer RestClientScaffold, but I can see the argument for it being too long. Any name is ultimately going to involve some tradeoffs and compromises, and RestClient.jl seems a perfectly fine choice.
Can this package handle with binary format data in communication that support WebSocket, TCP protocol ? The data in the body of the packet is Protobuf codec.
Here’s another formulation of the same general naming advice:
CONSIDER using plural namespace names where appropriate.
I think a plural S is almost always applicable - we are stuck with the name forever - the cost of an extra S is negligible. The cost of singular is potentially added friction down the line.
Just to clarify, and sorry for repeating an argument made in the General registry PR, but I guess my main argument for the pluralised version is that I do think that, at least eventually, there will be a need for a type of which you can create multiple instances (multiple clients), cf., e.g., connecting to multiple services with the same API.
It would also be nice with a poll that includes the other suggested names, e.g., RestClientScaffold, RestClientMacros (and multiple choice, please). Not sure if there has been other suggestions?
Edit:
I got some input from long-time community members supporting RestClientScaffold, or a non-systematic name - rather than RestClient/RestClients - similar to @digital_carver.
Update: RestClient.jl has just had its registration go through, with a few improvements to the docs/API thanks to some feedback from @stemann
I hope it will prove useful for anybody looking to wrap a REST-ish API in Julia.
In the future, I’d love to add a framework to make common authentication schemes easier, and with the upcoming Pkg.jl app support I think it would be really neat to make a code-generator tool that produced a package for a particular API from an OpenAPI definition.
I’d like to get to these eventually, but in the meantime PRs are welcome!
If you’ve tried RestClient.jl and found that it wasn’t handling rate-limiting properly for an API you tried, or that the debugging help was less useful that you expected, or that you didn’t see the expected kind of error for a failed request, I’d encourage you to check out v1.0.2 that’s just been released
I’ve mentioned the debugging a few times I think, but never actually shared a screenshot, so as an incentive/taster, here’s what you’ve been missing out on:
CONSIDER using plural namespace names where appropriate.
