RPC
Simple RPC style APIs with generated clients & servers.
About
All RPC methods are invoked with the POST method, and the RPC method name is placed in the URL path. Input is passed as a JSON object in the body, following a JSON response for the output as shown here:
$ curl -d '{ "project_id": "ping_production" }' https://api.example.com/get_alerts
{
"alerts": [...]
}
All inputs are objects, all outputs are objects, this improves future-proofing as additional fields can be added without breaking existing clients. This is similar to the approach AWS takes with their APIs.
Commands
There are several commands provided for generating clients, servers, and documentation. Each of these commands accept a -schema
flag defaulting to schema.json
, see the -h
help output for additional usage details.
Clients
rpc-dotnet-client
generates .NET clientsrpc-ruby-client
generates Ruby clientsrpc-php-client
generates PHP clientsrpc-elm-client
generates Elm clientsrpc-go-client
generates Go clientsrpc-go-types
generates Go type definitionsrpc-ts-client
generates TypeScript clients
Servers
rpc-go-server
generates Go servers
Documentation
rpc-md-docs
generates markdown documentation
Schemas
Currently the schemas are loosely a superset of JSON Schema, however, this is a work in progress. See the example schema.
FAQ
Why did you create this project?
There are many great options when it comes to building APIs, but to me the most important aspect is simplicity, for myself and for the end user. Simple JSON in, and JSON out is appropriate for 99% of my API work, there's no need for the additional performance provided by alternative encoding schemes, and rarely a need for more complex features such as bi-directional streaming provided by gRPC.Should I use this in production?
Only if you're confident that it supports everything you need, or you're comfortable with forking. I created this project for my work at Apex Software, it may not suit your needs.Why JSON schemas?
I think concise schemas using a DSL are great, until they're a limiting factor. Personally I have no problem with JSON, and it's easy to expand upon when you introduce a new feature, such as inline examples for documentation.Why doesn't it follow the JSON-RPC spec?
I would argue this spec is outdated, there is little reason to support batching at the request level, as HTTP/2 handles this for you.What does the client output look like?
See the Apex Logs Go client for an example, client code is designed to be concise and idiomatic.Sponsored by my GitHub sponsors: