The problem is that clients generally have a bunch of verbs they need to do. You have to design your objects and permissions just right such that clients can do all their verbs without an attacker being able to PATCH "payment_status" from "Requires Payment" to "Payment Confirmed".
RPC uses verbs, so that could just be the SubmitPayment RPC's job. In REST, the correct design would be to give permission to POST a "Payment" object and base "payment_status" on whether that has been done.
It fixes a lot of the problematic stuff with grpc and I'm excited for webtransport to finally be accepted by safari so connectrpc can develop better streaming.
I initially thought https://buf.build was overkill, but the killer feature was being able to import 3rd party proto files without having to download them individually:
The automatic SDK creation is also huge. I was going to grab a screenshot praising it auto-generating SDKs for ~9 languages, but it looks like they updated in the past day or two and now I count 16 languages, plus OpenAPI and some other new stuff.
> It fixes a lot of the problematic stuff with grpc and I'm excited for webtransport to finally be accepted by safari so connectrpc can develop better streaming.
We developed a small WebSocket-based wrapper for ConnectRPC streaming, just to make it work with ReactNative. But it also allows us to use bidirectional streaming in the browser.
The auto-generated SDKs are very useful here. An API customer doesn't have to learn protobuf or install any tooling. Plus they can fall back to JSON without any fuss. Connectrpc is much better at that than my envoy transcoder was.
If you're thinking from the API author's point of view, I might agree with you if there was a ubiquitous JSON annotation standard for marking optional/nullable values, but I am sick of working with APIs that document endpoints with a single JSON example and I don't want to inflict that on anyone else.
It doesn't use protocol buffers any more than gRPC does, which is to say it only uses them if you choose to use them. gRPC is payload agnostic by design. Use CSV if you'd rather. It's up to you.
I think it's become an industry term. This isn't the first article or product I've seen using it to refer to a 3d printed object that reversibly transforms without mechanical input.
Is there any link to “ace” meaning a tennis serve that the defending player fails to make any contact with? I could see the parallel with a “cheese” strategy being an unexpectedly fast attack.
I like the theory of traffic that basically says traffic will always make the best mode of transportation as bad as the second best.
The problem with buses is that car traffic can never be bad enough to make cars worse than buses. Buses are doomed to always be worse than cars unless they have dedicated lanes or parking is unbearable. So cars slow down to equal the metro system, bikes, ferries, etc.
A dedicated bus lane can speed up cars more than another car lane because it pulls traffic off the road until driving convenience equals bus convenience.
I’d say a cherry picked example is backed by random chance (possibly counter to the trend) while a poster child example has an explanation (not necessarily correct) for being the most sensitive to the variable being changed.
Much of Europe seems to do fine orienting their consumption and recycling around glass (including wash+reuse). I was surprised I didn’t even see aluminum recycling because it was so rare to see a can.
I believe there was a study that showed a mix of behaviors because populations with cooperative individuals out-compete in plentiful times and selfish individuals out-compete in scarce times. Hard to Google now because of selfish gene theory.
The problem is that clients generally have a bunch of verbs they need to do. You have to design your objects and permissions just right such that clients can do all their verbs without an attacker being able to PATCH "payment_status" from "Requires Payment" to "Payment Confirmed".
RPC uses verbs, so that could just be the SubmitPayment RPC's job. In REST, the correct design would be to give permission to POST a "Payment" object and base "payment_status" on whether that has been done.