[pre-ANN] RestClient.jl

Package Announcements
21

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.

3 Likes
22

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.

23

This. Pluralizing the package name in this way would be a mistake.

2 Likes
24

Here’s another formulation of the same general naming advice:

:check_mark: 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.

25

It’s not appropriate here! I don’t even know why we’re having this discussion!

26

Because we disagree :blush:

1 Like
27

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.

28

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.

So I’ll dip a toe into an alternative poll:

  • Some non-systematic name
  • RestClientScaffold
  • RestClientMacros
  • RestClient
  • RestClients
0 voters
29

Update: RestClient.jl has just had its registration go through, with a few improvements to the docs/API thanks to some feedback from @stemann :slight_smile:

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!

10 Likes