4 ms·

This article does a disservice to the benefits of “Richardson Maturity Level 2” i.e. “Use REST verbs”. A standard set of methods—with agreed upon semantics—is

This article does a disservice to the benefits of “Richardson Maturity Level 2” i.e. “Use REST verbs”. A standard set of methods—with agreed upon semantics—is a huge architectural advantage over arbitrary “kingdom of nouns” RPC. I’d argue that by the time your API is consistently using URLs for all resources and HTTP verbs correctly for all methods to manipulate those resources, you’ve achieved tremendous gains over an RPC model even without HATEOAS.

sytringy05 4y ago
I wholeheartedly agree, which is why hardly anyone ever builds "REST" APIs. It doesn't really add that much to a data API
sanderjd 4y ago
Man I really disagree. I think the set of verbs on the write side in REST is weird and creates so much bikeshedding. I'd much rather write an RPC API with semantically meaningful verbs taking and returning semantically meaningful nouns. I don't design my library interfaces around the verbs that HTTP happens to define and I don't see why I should design my network application interfaces that way either.
sa46 4y ago
I'm on team RPC. I'll stay away from the term REST since my beef is with HTTP APIs that mix transport and application concerns. - The Kingdom of Nouns comparison is forced. Yegge's complaint is that nouns own the verbs, meaning Java doesn't have first-class functions. The closest remote analog might be promise-pipelining which doesn't have much headway other than a single implementation for Cap-n-proto. - RPC APIs are more consistent than an HTTP API. With HTTP, a unique method requires both a path and method, and if you're really unlucky, the method is polymorphic based on the contents of the request body. - HTTP API requests can transport in different ways: request body, query parameters, HTTP path, and if you're really unlucky, headers. Tremendous gains doesn't match my experience. The first step in using a HTTP API is to wrap it with an OpenAPI generator to build a consistent way to invoke the API, reinventing RPC client stubs in the process.

sytringy05 4y ago

I wholeheartedly agree, which is why hardly anyone ever builds "REST" APIs. It doesn't really add that much to a data API

sanderjd 4y ago

Man I really disagree. I think the set of verbs on the write side in REST is weird and creates so much bikeshedding. I'd much rather write an RPC API with semantically meaningful verbs taking and returning semantically meaningful nouns. I don't design my library interfaces around the verbs that HTTP happens to define and I don't see why I should design my network application interfaces that way either.

sa46 4y ago

I'm on team RPC. I'll stay away from the term REST since my beef is with HTTP APIs that mix transport and application concerns. - The Kingdom of Nouns comparison is forced. Yegge's complaint is that nouns own the verbs, meaning Java doesn't have first-class functions. The closest remote analog might be promise-pipelining which doesn't have much headway other than a single implementation for Cap-n-proto. - RPC APIs are more consistent than an HTTP API. With HTTP, a unique method requires both a path and method, and if you're really unlucky, the method is polymorphic based on the contents of the request body. - HTTP API requests can transport in different ways: request body, query parameters, HTTP path, and if you're really unlucky, headers. Tremendous gains doesn't match my experience. The first step in using a HTTP API is to wrap it with an OpenAPI generator to build a consistent way to invoke the API, reinventing RPC client stubs in the process.