Skip to content
/ xrpc Public

Simple, production ready Java API server built on top of functional composition.

License

Notifications You must be signed in to change notification settings

Nordstrom/xrpc

Repository files navigation

xrpc

Build Status Download

Xrpc is a framework for creating production quality API services on top of Netty. The framework helps to encapsulate our best practices and provides sane (and safe) defaults.

It currently supports the http/1.1 and the http/2 protocols. It does so interchangeably, i.e your implementation does not need to change and it will automatically respond to a http/1.1 and a http/2 client the same way. The user is free to determine whatever payload they would like, but our recommendation is JSON where you don't control both ends and protobuf (version 3) where you do.

Running the demos

Running the people demo app in a test server

$ ./bin/startPeopleTestServer.sh

Basic http set

$ curl -k -d '{"name": "bob"}' -X POST https://localhost:8080/people

Basic http/2 get

Note: This demo requires curl with http/2

See: https://simonecarletti.com/blog/2016/01/http2-curl-macosx/

$ curl -k  https://localhost:8080/people
[{"name":"bob"}]
$ curl -k  https://localhost:8080/people --http1.1
[{"name":"bob"}]

Running the dino demo app in a test server

Run the dino app server to demo proto buffer handling.

$ ./bin/startDinoTestServer.sh

Proto http set

Note: This demo requires curl with http/2

See: https://simonecarletti.com/blog/2016/01/http2-curl-macosx/

$ java -cp demos/dino/build/libs/xrpc-dino-demo-0.1.1-SNAPSHOT-all.jar \
    com.nordstrom.xrpc.demos.dino.DinoSetEncoder trex blue | \
    curl -k -X GET https://localhost:8080/DinoService/SetDino --data-binary @-

Proto http get

$ java -cp demos/dino/build/libs/xrpc-dino-demo-0.1.1-SNAPSHOT-all.jar \
    com.nordstrom.xrpc.demos.dino.DinoGetRequestEncoder trex | \
    curl -k -X GET https://localhost:8080/DinoService/GetDino --data-binary @-
trexblue

Admin routes

xrpc comes with some built in admin routes. See also AdminHandlers.java.

Admin routes are split into two groups: Informational routes, which may contain internally-sensitive info; and unsafe routes, which can update a running server, and should be exposed only to a subset of users. These can be enabled with the admin_routes.enable_info and admin_routes.enable_unsafe flags.

Informational routes are enabled by default, while unsafe routes are disabled by default.

Informational routes:

  • /metrics -> Returns the metrics reporters in JSON format
  • /health -> Expose a summary of downstream health checks
  • /ping -> Responds with a 200-OK status code and the text 'PONG'
  • /ready -> Exposes a Kubernetes or ELB specific healthcheck for liveliness

Unsafe routes:

  • /restart -> Restart service
  • /killkillkill -> Shutdown service
  • /gc: Request a garbage collection from the JVM

Contributing

Please see the contributing guide for details on contributing to this repository.