14 ms·

Ask HN: Why isn't JSON-RPC more widely adopted?

151 points by vyrotek 4y ago

JSON-RPC / OpenRPC seems like a great option for APIs. Why isn't it adopted more widely? Many of the APIs of projects I've worked with look like essentially like RPC style calls. The URLs are structured as action/method names to do specific things. I like many of the benefits to an RPC approach compared to REST, GraphQL, or gRPC-Web. Unfortunately, the client code generation with popular options feels clunky when you want to use them in an RPC style. It seems like JSON-RPC would be better. https://open-rpc.org https://open-rpc.org https://www.jsonrpc.org https://www.jsonrpc.org

vyrotek 4y ago
[dead]
joshxyz 4y ago
For me, tradeoffs. Methods can be expressed in http method, and resource can be expressed in url. Response status can be expressed in http statuses. Some people prefer that for lower payload size. Others prefer byte encoded payloads like msgpack instead of json. In trading platform api's i've noticed that. Also, using url based resources lets you route these requests at the network proxy level (caddy haproxy nginx envoy traefik etc).
- hinkley 4y ago
  > Response status can be expressed in http statuses. This also simplifies circuit breaker work. The more error states you can interpret at the HTTP protocol layer the simpler it is to implement resiliency behavior. If you have to keep parsing responses looking for errors then you have to instrument every single call site separately - and distinctly. The more variation the harder it is to validate that they work properly.
  - grogenaut 4y ago
    Funny enough I found that rolling most of the error types into one error type of circuit level that is either server failure or application logic failure is really where we wanted to go with circuit breakers. Having many new error types and not making the compiler and force you to check for those error types causes new errors to show up in an existing RPC method and no one notices it. Worse it either gets accidentally thrown into server errors which causes circuits to close when they shouldn't because it's actually a problem in the calling service, or they get thrown into user cases when they should actually be server failures and services continue to slam services that are actually broken. At work we mostly got it down to those two areas with lots of nuances under the business logic level issues as opposed to the server issues. However I don't think that using hundreds of status codes is the right way to go about it those two classes seem to be a really good place at the Hep binding and circuit breaker level. Circuit breakers in general are kind of tough.
    - hinkley 4y ago
      You can think of REST as having 600 status codes, or you can think of it as having about seven. - Enjoy - no it's over here - What are you talking about? - Who the hell are you? - Not for you - Nothing's here - I fucked up Only the last one should be associated with circuit breakers, which I think you already get. Then it's just two values to worry about. < 500, and >= 500
      - grogenaut 4y ago
        Oh I 100% agree with you.. though I think you're missing "you fucked up". My point is more just that people mess up and blur the lines accidentally either throwing exceptions which get propagated up as internal service errors when they should actually get run across the wire as business logic errors as part of you fucked up. Or really they didn't guard their code correctly and you get we fucked up when you really meant say overloaded. And it does start getting really blurry when you get into you fucked up. Or you are fucking up so hard that we fucked up and in fact our fucking up everybody else.
        hinkley 4y ago
        400 You Fucked Up aka "What are you talking about?"
        grogenaut 4y ago
        aah missed it, I was cooking dinner. 100% agreed.
        hinkley 4y ago
        Originally I had them in random order and then I sorted them to try to make it easier for people to guess the status code from the colloquial description :)
        grogenaut 4y ago
vbezhenar 4y ago
Fashion. Lots of modern development practices is fashion-driven. JSON-RPC sounds too old.
- cm2187 4y ago
  And I am still struggling about the argument of why SOAP is bad but JSON RPC is good. The xml vs json debate is a tab vs double space debate to me.
  - jeltz 4y ago
    I have done a ton of integrations including many SOAP ones and it is because the SOAP standard is way too big, especially if we include XSDs. I have never used a SOAP library which implements the whole spec and it is very common for XSDs generated by one SOAP library to generate incompatible client code if you use another library (e.g. .NET and Java SOAP libraries are not compatible in some edge cases). I have quite often had to manually implement my own bespoke SOAP client (on top of some XML library obviously) due to the popular SOAP libraries not supporting the XSD I got. So SOAP is too big and all or virtually all libraries are more or less broken. I have never personally worked with such a broken mess of a protocol as the SOAP ecosystem. EDIFACT is supposed to be worse but I never worked with it, that was just some of my colleagues. JSON-RPC on the other hand is simple and all libraries I have seen implement it correctly and even if there is no library you can easily handroll everything.
    - magicalhippo 4y ago
      > EDIFACT is supposed to be worse I've worked with all three, and I think SOAP is the worst. EDIFACT is huge, but the structuring of the elements are pretty well defined. I've had to both consume and generate non-trivial EDIFACTs and while it looks quite weird it's easy to do and easy to debug, at least in my experience. Except for trivial stuff, SOAP as always been a nightmare for me. We've tried tooling but there always incompatibilities and workarounds needed in our experience. These days I manually generate the SOAP envelopes for each integration we do, with potentially some processing of the payloads as well. While XML is verbose, with a good XSD that doesn't try to be fancy I find it quite nice to work with. Even the signed XML stuff (XMLDSIG), which while it took some time getting into, turned out to be not hard to implement due to tools and libraries that worked. So XML in itself is nice, it's just SOAP that manages to make it all hard for no good reason. JSON-RPC is easy enough, tons of JSON libraries out there that can be used if you need to hand-roll.
michaelsalim 4y ago
Honestly, I think most projects just use a mix of whatever the author likes most (Except for frameworks where it's predetermined). Most would say they use REST but if you look closer they actually aren't. I'm also on the opinion that it doesn't really matter as long as it's documented well. I've never used JSON-RPC but from the little I've read, the part it is useful for is exactly the part people often customize.
roywashere 4y ago
I previously worked on an embedded device with a JSON/RPC over WebSockets API. I needed to use the API from a web browser context. There is not so much tooling for JSON/RPC in general. But it is very simple. I wrote my own client library wrapper that did the connection handling and request/response mapping. You'll probably want to do something like that to be able to handle requests that take a long time, that need to be retried, to re-open closed websockets for some reason or such. But if you have that, it's OK. I was not aware of the open-rpc 'schema' stuff, that looks very interesting, simple and useful
chubot 4y ago
Read about the important of idempotence in distributed systems HTTP GET is idempotent, which seems trivial, but it's worth more than people think. With JSON-RPC you can't safely retry any RPC, and that matters at scale! (If the transport is HTTP, I'm pretty sure all JSON-RPC are POSTs. JSON-RPC can be good for local communication like language servers, where you don't really care about retrying or caching) FWIW Google had/has a very RPC-like model, and when I left many years ago there, I remember they came around to giving explicit guidance to use a REST-like model (which you can do in an RPC system). That is, where you have more nouns than verbs, and you GET nouns.
- dastbe 4y ago
  i think the benefit of client expectations around verbs isn’t the be-all-end-all. i can still write a non-idempotent fairly easily. writing resource oriented apis does benefit quite a bit, as it often forces you into good api patterns around idempotency. many aws apis and almost all new ones follow this pattern and they are much betterto integrate with because of it.
- pshirshov 4y ago
  > HTTP GET is idempotent Yeah, def getHandler() = { val a = randomString() + readDatabase(); writeDatabase(a); return a;}
  - yandie 4y ago
    Technically you can implement whatever you want under a `GET` - you can even stuff a body to a `GET` even though the RFC doesn't allow it (see ElasticSearch API). However that doesn't mean it's a good implementation. What you're doing there is gonna break caching for example, unless that's intended. If I'm calling a `GET` and your service is behaving like a `POST`, I'm not gonna be able to rely on standard semantics for a lot of things!!!
    - pshirshov 4y ago
      If you can't enforce a contract it's not a contract.
benatkin 4y ago
Lack of tooling, plus gRPC being faster and safer than JSON-RPC while being as convenient as JSON-RPC except for requiring tooling. Also it brands itself as an alternative to REST while gRPC is branded more as being complementary to REST. Disliking REST is a huge hangup for me.
- jeltz 4y ago
  What is wrong with disliking rest? The more I use rest and the older I get the less I like it. Rest always looks so simple at first but then you realize that e.g. the size of the filter clauses for listing some resource exceed the maximum reasonable URL and you need to turn it into a post. And it is also very common that a lot of what you are doing does not in any way match to any easy to grok resources so you just end up with some kind of RPC anyway. I feel I waste too much time on pointless choices when designing Rest API:s and that designing an RPC API often is more straightforward. Personally I find JSON-RPC pretty meh and do not have that big of an issue with Rest, but I can definitely see the perspective of those who dislike Rest. Rest has it issues.
tptacek 4y ago
Perhaps, by the time they decide on a formal RPC standard, people conclude they might as well use a compact optimized RPC standard, like gRPC. REST-ish JSON APIs work fine and are universally familiar. What's the big advantage of encoding whole requests into JSON blobs, rather than just URL routing? If I'm going to do that, why wouldn't I just use GraphQL, and get the graph traversal part for free?
- dastbe 4y ago
  there is something nice about being able to just write some json and curl an endpoint. getting to this point with grpc is effort.
  - jiggawatts 4y ago
    This to me always feels like someone saying it's nice to be able to just pour crude into a couple of buckets and transport them around in the back of a truck when the goal is to build an oil refinery. This kind of "make the trivial part easy", "get started quick", "need no tooling" approach feels fast... at first, but then very quickly runs into nigh insurmountable problems. A great analogy I heard was: "If your plan is to go to the moon, you won't get there by making a fast bus."
    - harrisonjackson 4y ago
      Most crud apps are not the equivalent of an oil refinery.
      - taeric 4y ago
        At the same time, most crud apps need auth and a whole lot of other considerations. Is it neat they I can copy as curl a request to replay? Yeah. But, that isn't too hard to do with most any framework, is it?
        dastbe 4y ago
        do it with grpc and regular curl.
erdaniels 4y ago
For my current job, I speced out what was needed for an RPC solution. I ended up basically coming up with what JSON-RPC provides but was missing a few things. 1. Binary support for non-web clients 2. Robust code generation 3. First-class cancellation/deadline concepts 4. More guidance around a standard HTTP transport; kind of related to 2 5. Simple schema/type definitions to assist in code generation and API ecosystems Ultimately, we went with gRPC and it has been pretty nice. The code generation is mostly good and where it isn't, we can make our own wrapping code. There have definitely been some downsides and gotchas when it comes to the servers, specifically around client streaming and bi-di requests. Also, grpc-web is really not great and is the biggest downside so far. Overall though, it feels worth it for our use case. Protobuf has been great.
- blank_fan_pill 4y ago
  what have you not liked about grpc-web?
  - vyrotek 4y ago
    Personally, I find gRPC-Web very attractive but the current state of TypeScript/JS code-gen is very confusing and lacking. I would love something like https://orval.dev https://orval.dev for gRPC-web. Have I missed something or is it just early to expect it? I tried a few libraries but couldn't get them to work or would generate unappealing results. I believe I'm hitting this issue with my local experiments. https://github.com/grpc/grpc-web/issues/535 https://github.com/grpc/grpc-web/issues/535 UPDATE: I was able to get something working with these from a ReactJS app! Server: https://learn.microsoft.com/en-us/aspnet/core/grpc/grpcweb https://learn.microsoft.com/en-us/aspnet/core/grpc/grpcweb Client TS Gen: https://github.com/timostamm/protobuf-ts https://github.com/timostamm/protobuf-ts
    - erdaniels 4y ago
      Ah you should check out https://github.com/bufbuild/protobuf-es https://github.com/bufbuild/protobuf-es which feels great so far. Then there's connect by the same buf people but it has a grpc-web option https://connect.build/docs/web/getting-started/ https://connect.build/docs/web/getting-started/. The amount of code generated is also tiny, which I love.
morelisp 4y ago
> Many of the APIs of projects I've worked with look like essentially like RPC style calls. There are two correct responses to this: - Use a decent RPC framework to hide HTTP's semantics (which are not appropriate for RPC) and to get generally better but still widely-accessible tooling; I use gRPC but at this point there are a dozen good-enough ones (JSON-RPC not being among them). - Design a REST, or at least REST-ish, API. Map your URLs to entities not actions or methods. Make each entity have a canonical URL. Use content negotiation. And so on. It's more work but you're also available to a lot more real HTTP clients. There is also a wrong answer: - Continue trying to do RPC over HTTP semantics with an inefficient format and assume that having a standards document per se solves literally any problem.
bullen 4y ago
I would say not many data structures requires hierarchy, which kinda is the point of JSON or XML before that. Those structures that do, are often persistent; so the right trade-off might be to make your protocols more lightweight (I use |;, separation of just text) and then use JSON for your database objects (fits well with my |;, separators). Here are two examples of "packets": Movement: "move|<session>|<x>,<y>,<z>|<x>,<y>,<z>,<w>|walk" (where x,y,z,w are floats) Storage: "save|<session>|{"name": "torch", "amount": 3}" You can read more here: http://fuse.rupy.se/doc/game_networking_json_vs_custom_binary_protocol.txt http://fuse.rupy.se/doc/game_networking_json_vs_custom_binar...
user3939382 4y ago
Or this https://jsonapi.org/ https://jsonapi.org/
crazygringo 4y ago
Most API's don't need to receive deeply hierarchical data. Function calls almost always take just a handful of values, and if you need the occasional array, that's quite easy to manage with duplicated keys ("...&filter=price<300&filter=color:red") or numbered suffixes ("...&filter5=price<300&filter6=color:red") or delimiters ("...&filter=price<300,color:red") as preferred. While if you do need something deeply hierarchical, there's a good chance it might be something massive and so you'll probably just pass a URL to it as a document, rather than embed it as parameters. So why use JSON for input if you don't need it? It's just using the simplest tools for the job. Since any web request already parses GET/POST parameters, why would you add JSON into the mix when the parameters can usually already handle what you're doing? (But if you did have an API where input was necessarily deeply flexibly hierarchical, JSON RPC could very well be the perfect tool for the job. Also, compare with API output which often is very deeply hierarchical, which is why JSON is so popular on the output side.)
- wruza 4y ago
  So why use JSON for input if you don't need it? Because next morning you start to need it and your API becomes inconsistent and your b2b buddies make a deep sigh which you can hear through a chat. Inconsistency is a minefield. Makes no sense to complicate everyones job out of the blue.
  - crazygringo 4y ago
    Overengineering is a slippery slope. And the reality is that in 99% of cases, you don't need it. If there's a single data value that needs a flexible JSON payload, then just put that as an encoded string in your GET/POST parameter. It's not "inconsistency", it's just a special case. Same as you might not need a floating point number anywhere except for one endpoint. Not a big deal. You don't need to migrate the entire call to JSON-RPC.
    - rerdavies 4y ago
      How do you return data?
    - 4y ago
djha-skin 4y ago
Parsing makes it hard. Consider writing an HTTP based RPC server. I parse the first line. It tells me the location and the method. Followed by a bunch of key value pair headers where both the key and the value are strings. So far so good, I could write all of the above in C or Go pretty easily. Finally comes the body. I can unmarshall this in Go or parse this in C easily because I can I know what to expect in the body by the time I get there. This is because I already know the method and location. Contrast this with JSON RPC. I have to partially parse the entire object before I know what function is being called. Only then can I fully parse the arguments because I don't know what type they are (or in other words, which struct the arguments correspond to) until I know what function is being called, what version of RPC is being used, etc. Super annoying. And HTTP is just sitting there waiting to be used. HTTP allows for incremental parsing. I can parse the first few lines separately from the body. It makes handling input really nice. Having everything in a single JSON object doesn't allow for incremental parsing because the standard says I can't guarantee order of key value pairs when an object is concerned.
- Scaevolus 4y ago
  Distinct RPCs being distinct URLs also makes it possible to easily route and load balance RPCs to different backends, which is lovely for scaling up.
  - throwawaymaths 4y ago
    At that point you're doing OpenAPI, which will dispense with the subject routing boilerplate of JSON rpc, and have a lighter payload that you have to do less work to understand (presumably the JSON schemas are similar to your db tables)
  - jacobsimon 4y ago
    When I’ve considered JSON-RPC in the past, the lack of easily identifiable URLs was the main drawback in my mind due to the difficulty of testing and debugging—the same reason I would never use gRPC or similar on my own projects. That said, I think a well-made browser extension would fix this issue for most people, similar to GraphQL, but it still introduces friction that isn’t immediately beneficial. I’d still give it a try in the future!
brap 4y ago
>It is transport agnostic in that the concepts can be used within the same process, over sockets, over http, websockets, or in many various message passing environments. I think tRPC sort of implements a transport layer for (a superset of) this, no?
hestefisk 4y ago
I like rpc because of its simplicity. Function call done over the wire. I want to just invoke a function somewhere without worrying about constraints of “style” (rest, graph quality, etc). Whether it’s json, xml, grpc etc underneath doesn’t really matter to me.
peterhunt 4y ago
IMO it’s two things. 1. REST positioned itself in opposition to RPC. The concept of RPC is a negative one in many engineers’ minds. 2. JSON-RPC isn’t that much better than passing your own JSON formatted messages over HTTP. So I don’t think it gets you too much incremental value these days. With that said I love JSON-RPC and tend to reach for it pretty often for prototypes or greenfield projects.
- pshirshov 4y ago
  > REST positioned itself in opposition to RPC. Whatever some people say, REST is a form of an RPC. If someone wants to object, they should think again and again and again.
  - w-j-w 4y ago
    [dead]
  - nsonha 4y ago
    said who? the historical context is that REST comes after SOAP, a very clunky implementation of RPC, and positioned itself as different. It got popular because of its ease of debugging. Conceptually there is another key difference that is REST revolving around standard HTTP verbs and encourages CRUD like APIs while RPC encourages APIs more like a non networked APIs
    - pshirshov 4y ago
      > said who Just think about it. For example, try to build isomorphism between REST and any RPC you want.
      - deleted 4y ago
        [deleted]
      - nsonha 4y ago
        What the hell is isomorphism, I'm a dum dum
jongjong 4y ago
Because JSON and RPC are two separate standards and don't need to be intermingled into a combined standard. It's relatively easy for clients to adapt to any JSON interface when integrating.
- drdaeman 4y ago
  RPC is not a standard, though? I believe it's merely a common name for a pattern, calling functions remotely. The details (how requests and responses are serialized and transported) is all that really matters. And given that XML-RPC is a thing, JSON-RPC was supposed to be its replacement (because it's easier to parse JSON than XML).
  - jongjong 4y ago
    My point still stands. It's not difficult to adapt a client for whatever combination of protocols and standards the server wants... RPC over HTTP or WebSockets or TCP or whatever... The server might want to use different protocols depending on the exact use case. There is no need to force the server to use a specific one. JSON-RPC has the same problem as WSDL... It would be useful if clients would discover the service and use it automatically... But that does not happen in practice. It's always a human who does the integration work manually because only a human can fully make sense of what kind of data is provided by various endpoints. You can't automate endpoint discovery and therefore there is no need for a single common standard to facilitate that.
nitwit005 4y ago
What problem are you trying to solve? gRPC uses protocol buffers, which had the goal of being smaller and faster to parse than XML. The issue it was trying to fix was the performance of XML. The JSON-RPC protocol itself doesn't seem to solve anything that the other options don't solve as well.
carom 4y ago
Every time I go to use JSON it is great until I remember it cannot represent 64 bit integers.
- jayd16 4y ago
  Huh? The json number spec does not specify a precision or size. Any limitation is from your parser.
- gabetax 4y ago
  This is a Javascript issue, not a JSON issue. The JSON spec doesn't apply any limits on the number type. ECMA-404 states: > JSON is agnostic about the semantics of numbers. In any programming language, there can be a variety of number types of various capacities and complements, fixed or floating, binary or decimal. That can make interchange between different programming languages difficult. JSON instead offers only the representation of numbers that humans use: a sequence of digits. All programming languages know how to make sense of digit sequences even if they disagree on internal representations. That is enough to allow interchange. It also explicitly excludes NaN encoding, which further distances itself from any coupling to IEEE floating point expectations.
  - jillesvangurp 4y ago
    Yep, if you use e.g. Java's jackson, you can configure it easily to deserialize numbers as BigInteger or BigDecimal instances. Useful trick if you need it and it really works. You can have arbitrary precision numbers in Json. Of course this does challenge most other parsers out there.
- vbezhenar 4y ago
  Use https://www.npmjs.com/package/json-bigint https://www.npmjs.com/package/json-bigint I think that one day browser will support it natively.
- RedShift1 4y ago
  In Javascript, when do you need to represent something larger than 2^53 anyway?
grogenaut 4y ago
I tried Json rpc, swagger, and json schema for a few use cases at work when we were deciding on our serialization format. The schema definition in it is really really ugly and I could barely get it to work. Also at the time (2015) the language support for that schema definition wasn't great. I also tried swagger at the time and there were quite a few things I just couldn't get it to do. If I couldn't get it to behave in a targeted research spike it was really going to be a non-starter for new employees trying to slam out features. These issues meant people would go with the losest typing or just "object" for a lot of items. One problem is that they both have the flexibility of XSD but whether a given laganguage will support that validation or do it correctly was spotty at best. We went with our own dumbed down version of GPRC called Twirp which is very very simplified. The schema language for proto3, which twirp uses, is a lot simpler to write, uses close to just native typing, and does a lot less. Doing less was actually nice because it meant less rules. I was able to implement the prototpe ruby version which someone else (thanks cyrus) put into production in under a day because there were so few rules but what it had gave us type safety. For years people really liked REST because it was "self describing via api" but it turns out no one cares, what they want is a client in the language they're using that works. They really don't care that much how the client is generated. So to me Interface Description Languages (IDLs) and a code gen step are what you want with some simple basic rules. We built a similar tool for config checking, and most of the features weren't used. But Twirp and this language removed a whole class of issues that had plagued us and caused outages for years around string vs int in configs and apis. Also, at our scale, for some services, proto or another binary format has substantial benefits. I'm not saying it matters for your service and human readable is great (we had to learn and built up tools to debug things, and kept json support in twirp exactly for the poor humans), but when you're sending a millon requests a second or so to a service, there is a noticeable cost equivalent to an engineer's salary in infra costs. But most people are not running at that scale. On the front end GQL worked better for us, it pushed the flexibility to the front end devs while we sorted out the back end over several years. The level of coupling we'd have had if we ran Twirp, Swagger, or anything else direct from front to back end would have made work 100 times harder. I was skeptical when they started but it's been a boon, and I was smart enough to let smart people be smart in an area I'm not smart in eg I stfu. Anyway TL;DR (at the end of course) there were better options for me such as Amazon's internal one, GRPC, Twirp, roll your own Proto based, and about a billion others. I'll also note the v1 spec wiki page link is broken.
blank_fan_pill 4y ago
How is gRPC-Web not an RPC approach?
twunde 4y ago
Generally speaking, json-rpc compares negatively to REST and to other RPC standards like gRPC or Thrift. REST is more popular, in large part because of Ruby on Rails, but also because it provides semantic meaning and a system that defines what the api call should be named. No need to look up the remote function, like you need to do for json-rpc. For those who prefer RPC calls, why not use a RPC system that compresses data efficiently and which use IDLs for code generation. Anecdotally, I found that many developers had difficulty understanding json-rpc, because it was so close to REST apis
austin-cheney 4y ago
I am using something similar to JSON-RPC over websockets in a personal project. It is far less of a hassle than HTTP, 8x faster, and less prone to failure.
user5678 4y ago
[dead]
splix 4y ago
I have experience working on some JSON RPC Load Balancer, and I can tell that it's one of the worst choices for an API: - Method Name is a part of the body itself. So you have to parse it to make a decision on how to dispatch it. That's an extra cost. - Error Code is a part of the response. So you have to parse it each time to figure out if it's a success. Also, some clients just give an HTTP Error Code instead. So you have to handle both. - It can also be batched. Which introduces a lot of unspecified use cases. - Like how are you supposed to dispatch those batched? Should they go to the same upstream? Or can it be parallelized? Should the order be preserved? - With batches, the slowest request always blocks the in-flight response. You have to wait for all calls to be finished before producing a final response. That's a huge performance bottleneck. Also, what you do if some of them never finished? - A lot of uncertainties about the ID. Especially because it can be a different type (int or string), which sometimes introduces two different handlers in the code. And there are no guarantees IDs are not repeating in the same batch. To make it worse, some clients rely only on the request/response order ignoring the IDs. - Another problem is that it has no idea of Metadata, which is important for many real systems. For example, to do an Auth. Or do Caching and other optimizations. So as an outcome, everyone just makes two layers. On the HTTP level, you have auth, routing, error handling, multiplexing, etc. And then you realize that JSON RPC only introduces extra complexity.
- jillesvangurp 4y ago
  Graphql shares many of the same issues. And yet it is popular. And arguably a lot more convoluted. The difference is basically schemas and client generation. The whole point of RPC is that the stuff that happens on the network is just a means to an end and you generate the code that does the server and client stubs that you call. I've seen just about anything on this front. People used to do SOAP which is all of the downsides of graphql and json rpc combined without most of the benefits. Stupidly complicated to do just about anything with it. It's a good reason people don't suggest that anymore for new APIs. REST APIs completely killed SOAP. The only places you see it these days are legacy systems from 15-20 years ago. The thing with just about any kind of parsing overhead on servers is that it is completely dwarfed by network IO getting to the server and then more IO for getting to a database, redis, etc. Add ORM to the mix and you typically get this unoptimized mix of multiple calls to a database (because most orms suck at optimizing their joins). We're talking fractions of a percent of the time spent here. Web servers don't commonly use a lot of CPU time until they are handling dozens/hundreds of requests per second. With a asynchronous IO, you can server thousands of requests. The bottleneck usually becomes your database. Not the webservers. Those tend to run on cheap vms. Add more to scale at the cost of 10-20$ per month. Back in the day when parsing overhead still mattered, we'd speed up our servers with a few simple tricks, which mainly boiled down to not buffering requests and responses. Use streaming parsers on the request payload, iteratively process whatever comes in, and stream the output as results become available. You'd be responding with the first bytes long before the last request byte had arrived. Great for processing large ndjson/csv files and responding with similar output. You can process mang GB of data with a single request this way. Doing this is hard but not impossible with modern asynchronous web framweworks. They all default to buffering everything and then processing and then responding. Reason: it's simpler and the performance difference simply does not matter. But it's still a useful trick if time to the first bytes of your response matters to you and you have a really fast, tightly tuned backend. This is how you get to sub ms responses.
rswail 4y ago
RPC is a fundamentally broken concept because it relies on both server and client being synchronized, which is brittle and requires whole system upgrades. Protobufs and things like optional fields etc help, but not that much. One of the problems is that RPC is procedural and treats the data as parameters to the function. REST says that the "data" (the resource) is the primary element and is oriented towards the original OO concept of message passing. RPC has been bad since the days of XDR and SunRPC, has repeated the same problems with CORBA, WS-, XML RPC, JSON RPC, Java RMI, etc etc. Programmers love it because it looks* like a standard function call, but the problems are hidden under the covers (versioning, network failures, idempotency, retries, etc).
- pjmlp 4y ago
  People keep advocating that REST isn't RPC, while almost no one uses it as it was originally proposed, almost every major product with REST APIs has client SDKs that wrap the boilerplate of doing REST calls, just like any RPC wire protocol.
ChuckMcM 4y ago
See SOAP[1] [1] https://www.w3.org/TR/soap/ https://www.w3.org/TR/soap/
mirekrusin 4y ago
We use jsonrpc over websockets in production for many years in trading services. It works very well. We use lightweight libraries that look like this [0] and this [1]. It's lightweight, fast, type safe, easy to maintain and debug etc. We use (compatible) extension of jsonrpc for async generators - yielding elements individially for longer array responses, transparent to the client, to avoid head of line blocking (haven't open source this yet, but will soon). Other than allowing error code to be string it's all pure jsonrpc 2.0. Supporting things like adaptive throttling (that dynamically adapts to client's connection speed) was very easy to implement as well. [0] https://github.com/preludejs/jsonrpc https://github.com/preludejs/jsonrpc [1] https://github.com/preludejs/refute https://github.com/preludejs/refute
unilynx 4y ago
I find it useful to link tightly coupled front and backends where scalability/load balancers aren’t a great concern and the API isn’t intended to be public. Otherwise I’d go for REST and openapi Lately I’ve been experimenting with using a generic proxy object on the client corresponding to a server side object that is the actual API, and defining a typescript interface that both the proxy and server version implement. It makes invoking backend APIs a lot nicer.
Traubenfuchs 4y ago
rest(ful) cargo cult Good luck trying to propose any kind of API that violates the blurry image others devs and architects have of rest(ful) APIs. No one got ever fired for going for a rest(ful) API.
deleted 4y ago
[deleted]
hknmtt 4y ago
i would because ** REST for API but i am already too used to write my APIs in protocol buffers so even though I have abandoned gRPC I still use PB and so I need rest-ish approach.
z3t4 4y ago
Because it's stateful. And a JSON-RPC call is not guaranteed to get something in return. When abstracted with timeouts and callbacks it works nice though. The big advantage is that it can run via any transport protocol, while compared to HTTP you have the transport protocol built in.
dvh 4y ago
The problem with using some standard like json-rpc instead of ad hoc API (aka fetch this URL and you'll receive this json) is that one day some 3rd party will use some obscure feature of that standard (like tunneling via email) and you'll be forced to implement it. Eventually every 3rd party will have slightly different implementation of that standard and you will have to make various customer specific workarounds. If it is ad hoc API, they tend to consume it as is and don't have stupid requests. Also every customer updates to different version of the standard at different times so it will be nightmare, where as if it is ad hoc API, everybody write it once and never touches it again. I find ad hoc apis vastly superior and more stable (as long as they remain simple).
RedShift1 4y ago
I use JSON-RPC as a standard to command devices that connect to a message bus (I use NATS: https://nats.io/ https://nats.io/). I wouldn't use it as an alternative to REST or GraphQL, they have different goals/use cases.
nsteel 4y ago
The spec promotes it as transport-agnostic. Out of interest, has anyone come across JSON-RPC transported over anything other than HTTP?
- Zanfa 4y ago
  I believe some text editors call LSP processes over sockets using JSON-RPC.
- TazeTSchnitzel 4y ago
  I somehow thought bitcoind used JSON-RPC over TCP, but it seems that it's actually HTTP? I don't understand why HTTP is used.
jcubic 4y ago
I was told by the author of tRPC, that they use JSON-RPC behind the scene.
- vyrotek 4y ago
  Whoa, that's news to me. Is this called out anywhere online? I've been following tRPC a bit and it looks really great. I only wish it wasn't locked into using TypeScript on the server. It's the dream dev experience I've been chasing. I'm trying to get as close as I can using auto-generated gRPC-Web.
talideon 4y ago
I think worth reading is "A Critique of the Remote Procedure Call Paradigm - 30 years later" (https://blog.carlosgaldino.com/a-critique-of-the-remote-procedure-call-paradigm-30-years-later.html https://blog.carlosgaldino.com/a-critique-of-the-remote-proc...), as well as Tanenbaum's original paper: https://www.cs.vu.nl/~ast/Publications/Papers/euteco-1988.pdf https://www.cs.vu.nl/~ast/Publications/Papers/euteco-1988.pd.... Sure, it's old, but still very relevant. gRPC does better against his criticisms than the likes of JSON-RPC does.

nsteel 4y ago

What do you think about a rebrand? How about jRPC?

vbezhenar 4y ago
There are some conventions that modern infrastructure expects. For example client does the request, some proxy intercepts the request, checks some things, then forwards the request. Another reverse-proxy on the server side again intercepts the request and routes it to the final web server. If one of the proxies receives HTTP 5xx, it might perform few retries. Devops people want to have some meaningful info in the URL, so they can write some security or routing logic. It might be useful for devops people to have not just 400, but many different response codes, like 400, 401, 403, 404 for different situations. They'll make metric out of it and set up an alerts. So if I would design modern RPC, I'd go the following route: 1. Do not make it protocol-agnostic, but rather embrace HTTP. Method+URL should contain routing information (jsonrpc method field). Errors should have a way to map on HTTP response codes. It does not mean that it's impossible to use it over say websocket, you just need to wrap it with HTTP-like structure. 2. Do not bind it to JSON-only. There should be a way to provide request parameters via URL query parameters, via JSON body and via protobuf body. Good server implementation should respect Content-Type and respect Accept HTTP headers. So I can call that method via cur, via some JS code or with optimized protobuf mobile SDK. JSON should be the main target, though, other encodings should be mapped to JSON. 3. Support meta-information, probably using something like JSON Schema or OpenAPI. 4. HTTP Method must be used as a caching and idempotency information. GET responses are cacheable. POST is not idempotent, etc. Actually it might look a little bit like REST. But I just tried to extract the most useful parts out of it and remove useless parts like coding some parameters in URL Path or the whole philosophy about entities and stuff. If you don't want to think about caching and idempotency stuff, you just use POST for your endpoints and that's perfectly fine.

BoorishBears 4y ago
Maybe should learn what an RFC is, and check out this one before you keep trying to counter the document that formally minted the verbs in the first place: https://www.rfc-editor.org/rfc/rfc2616#section-9.1.2 https://www.rfc-editor.org/rfc/rfc2616#section-9.1.2 See section 9.1.2: Idempotent Methods, where they succinctly address the point: > Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them. - It's funny, I wouldn't have thought the RFC needed to say this. I'd have thought it was a waste of words since it'd be obvious to absolutely anyone that you can't... what? magically force developers to not write a bit of code in a system you have literally no control over? Yet here we are, proving the authors well-prepared all these years later.
- pshirshov 4y ago
  > Naturally, it is not possible to ensure that the server does not generate side-effects Of course it's possible, there are ways to guarantee that and to prove that. That's an area of ongoing research. E.g. https://link.springer.com/chapter/10.1007/978-3-642-36594-2_13 https://link.springer.com/chapter/10.1007/978-3-642-36594-2_... Though I've said just one thing - you can't expect that a GET query would be idempotent. You may only hope.
  - ninthcat 4y ago
    It is not possible to prove that calling the server will not produce side effects. The link you provided does not address side effects, but correctness, which is much weaker. A trivial example is that calling the server will consume electricity.
    - pshirshov 4y ago
      "Side effect" is a breakage of referential transparency. Depending on your model it can be proven. Electricity consumption won't be a side effect in any reasonable model.
      - notwedtm 4y ago
        What are you going on about? This feels like someone who's just read their first compsci book and now thinks they can build New Internet. Surely this is a troll...
        pshirshov 4y ago
        I'm saying that unenforceable contracts, like the "idempotence" of GET requests are no better than an annotation on a method in a conventional RPC IDL. If fact the latter is better, because it may be somehow enforced by cogen if you code-generate into a language which may, for example, enforce purity or totality. And the whole story about "REST not being an RPC" or "there is purity/idempotence/whatever in REST because RFC says that GETs are pure/idempotent/whatever" makes very little sense. At the same time I'm saying that it's total bullshit when someone says that it's not possible to enforce lack of side effects (like in referential transparency) during a remote call.
  - BoorishBears 4y ago
    SCC is so unrelated to anything even being remotely discussed, that it would be an insult to the term "orthogonal" to describe it as such. It's such an off-the-wall connection I can hardly refute it: it's like we're talking about toasters and you dived into talking about CRISPR because I said the word "crispy". If anything it'd imply you're not familiar with CRISPR or toasters. > Though I've said just one thing - you can't expect that a GET query would be idempotent. You may only hope. I guess you should look up what it means to expect something. In the context of your sentence hope and expect are synonymous*, so maybe you meant you can't guarantee? And even ignoring that mistake, it's not really useful to say "You can't be sure something doesn't follow guidance, you can only expect it" because that's tautological. Guidance in and of itself doesn't have any way to assert direct influence on an implementation, that's why it's literally called guide·ance. *before you use that to dive into a grammatical diversion, that is not generally the case, only specifically in your use.
    - pshirshov 4y ago
      > SCC is so unrelated to anything even being remotely Let's assume we make a remote call with a list of VM instructions for a virtual machine which has no access to any I/O. Now we only need to prove the correctness of the answer. Whatever you do on the remote side, you won't be able to make your computation impure. Yes, you still may write logs or sleep but it won't break referential transparency, there will be no way to return two different accepted results for the same inputs. You may even have I/O in some very limited form. You don't have to supply the code. If you don't agree, show me side effects in EVM. > In the context of your sentence hope and expect are synonymous Only in your eyes. Anyway, I've been saying that REST is too unformal and weak-typed.
      - BoorishBears 4y ago
        When you're this far out of your depth, it may be best to stop floundering and see if you can float. You implicitly revised your previous statements, and the revised point is even further off base (I mean, now you're showing you don't know the difference between REST and HTTP verbs?) At some point just take it as a learning experience that non-sequitur about verifiable computing don't have any of the "shock and awe" on HN that they might on and your Facebook wall... You should stick to things you understand if you insist on making authoritative statements. - By the way: language doesn't only work "in my eyes", words have meaning, learn those meanings before you use them.

daxfohl 4y ago

Pretty much this. I was very anti-REST back circa 2015-2017 when I started doing web dev. I was doing solo work and all my services were JSON-RPC (I can't remember whether that was an actual standard then or if I just rigged it). I was (and still am!) into functional programming, and RPC seemed to fit better: it's just a remote function call. Nakedly PUTting a resource just seemed to violate my idea of good architecture. In 2017 I left to join Azure, which is REST-heavy (in all this, I mean "modern" REST, not "Fielding" REST). I hated it at first, but eventually saw how nice it is to have the conventions. Less to explain in public API docs, easier to generate scaffolding, common themes of how to destructure incoming requests in middleware handlers and middle-tier services, a standard way to serialize references to resources across the platform. I was a convert. Moving to google in 2021, they're still very RPC, and it feels so cluttered and arbitrary. I'm not there anymore. Yes, REST is roughly just some conventions around RPC at the core (though you get things like caching for free), but ultimately it's a really nice set of conventions that are easy to follow and limit surprise, and are standard across the industry. As one user commented, you do sometimes have to work around REST to get it to fit, typically futzing in headers or request metadata, but to me the pros outweigh the cons.

gspetr 4y ago
Can you point to some sources of information about the modern REST you are talking about?
- talideon 4y ago
  "Modern" REST generally disposes of things like hypertext and representations as being too complex, instead leaning on things Swagger/OpenAPI to declare an IDL equivalent, so you're getting effectively an RPC system with some of the guarantees you'd get from REST. Azure's APIs are more RESTful than most: they actually bother using resource URLs as identifiers. I've never understood what people find so hard about HATEOAS. It's like people have never interacted with a HTML form or followed links to stuff, or have difficulty figuring out how webpages can consist of multiple linked resources.
  - naasking 4y ago
    > I've never understood what people find so hard about HATEOAS. It's like people have never interacted with a HTML form or followed links to stuff, or have difficulty figuring out how webpages can consist of multiple linked resources. Or that an object graph of a system is a web of linked resources, and that every program has an entry point object/interface from which you can navigate to any part of that object graph, just like in REST.
  - spdionis 4y ago
    It's not hard, it's just wasteful and not very useful.
  - daxfohl 4y ago
    Yes this is what I meant. The way Azure does it is kind of nice (to me at least, as an ex member of ARM) because ARM can generically check access just by the URIs. The downside though is that the URI also includes the subscription and tenant id, so ARM has to deal with the URI being stale after stuff gets moved around. And then the advent of management groups and cross-tenant access made it so it's not quite so straightforward anymore. But it was still quite useful.
  - still_grokking 4y ago
    > "Modern" REST generally disposes of things like hypertext and representations as being too complex, instead leaning on things Swagger/OpenAPI to declare an IDL equivalent, so you're getting effectively an RPC system Now the question is: Why do people insist to calling some (no standardized) ad hoc RPC protocol "REST(full)"?

nsteel 4y ago

I've only limited experience with it but it does the job OK. Can you expand on "nigh insurmountable problems"?

jiggawatts 4y ago
An RPC interface is the same as any other interface in programming, but with more complexity to deal with. Hence, just as we have the "proper tooling" to deal with internal interfaces, there's a stack of tooling for dealing with RPC interfaces. Advice that I provide to dev teams is that every time you introduce a network hop, you're more-or-less going to triple the complexity of that interface boundary. Before, where you might have had a simple function call such as "foo(p1,p2);", you now have to: 1) Define a message type that encapsulates the p1 & p2 arguments into a single thing. 2) Do this on both server and client, consistently, and allowing for versioning to handle rolling upgrades. 3) Encode and decode your actual programming types into this blob. (Across dissimilar languages this is especially fun.) 4) Write the "RPC server" code. 5) Write the "RPC client" code. That last one is the bit that a lot of developers skip, or make it "other people's problem". Imagine you're writing a server for an RPC endpoint. You (internally) define some return message type, call "toJson()" or whatever on it, return it from some HTTP REST route mapping... and you're done. You're done. You. Queue the potentially dozens, hundreds, or possibly hundreds of thousands of developers that have to bang out the client side of this. By hand. Typing it in, based on your documentation... of which there is likely none. Or it's in HTML and not machine readable. They're going to make mistakes. They will assume something is nullable when it isn't, or not-nullable when it is. They'll have no idea what error messages can be expected, or in what format, and the only way they'll find out is... in production. Rare errors they'll likely never handle properly. Meanwhile, with "proper tooling" the server-side developer uses a formal Interface Definition Language (IDL) such as the one used by CORBA, DCOM+, gRPC, Cap'n Proto, or whatever. This IDL is ingested by tools(!) on both the server and client, generating reams of "stub" code, ready for business logic. Better tools will automatically insert the matching doc-comments, so that when typing in a proper IDE (which you use, right?), then hovering over a function definition will show its help summary text live, in context. In enterprise settings, it's common to see code that's basically just a dozen APIs glued together to do something useful. If those APIs are hand-rolled REST, then this takes months of development effort, and then endless maintenance as things just break in weird and unexpected ways... in production. If those APIs are generated with tooling, then hundreds of kilobytes of that boilerplate RPC client code can be spat out in just minutes of effort. More importantly, nobody then ever needs curl to diagnose random errors in production, because the code won't even compile if something doesn't match the schema. If something returns an unexpected value, nobody needs to inspect the wire traffic, because the deserialized value is in memory, visible to a debugger or log trace. Getting "into the weeds" of banging out RPC requests by hand is for people that don't realise that they're not supposed to care what the wire format is! It really is night & day. For example, back in 2006 with Windows Communication Foundation, you could just paste a single URL into Visual Studio, and then you'd be off to the races. It would generate everything for you, and you could just start programming your business logic immediately.
- theamk 4y ago
  If you are in the "enterprise setting" and your languages/frameworks/standards require hundreds of kilobytes of boilerplate RPC code, then yes, you probably some tooling about this. But it does not have to be this way. For my work, I've written a few smaller scripts that talk to things like Github and Jira using only python stdlib. There are no third-party libraries or codegen tools, there is not even install step - you check out the code and run, and it _just works_. And users love it and use every day, and the fact that I can tell them "no dependencies needed, just make sure you have our standard corporate Linux install" lets those scripts be used by many different teams. Some things require mountains of code, but not all of them.
- nsteel 4y ago
  Our Python implementation automagically handles all the sever-side plumbing and Just Works. I didn't write it but think it's neat and good enough. Our client side story isn't so good, as your reply predicts. Our primary JS websocket client uses introspection so that's no burden. But we also ship a manually constructed matching Typescript interface which does get out of sync. And other clients are left out on their own. It'd be nice if the codegen tools linked in the original post were further along as this would make life for generic clients much easier. I've been watching them for some years but they don't seem to be going anywhere and I'm comfortable enough with our custom implementation.

nabla9 4y ago

No, it's not. You are making stuff up on the fly. RPC does not mean "Transferring bytes between computers across networks using some protocol." RPC = Remote Procedural Call. REST = Representational State Transfer. REST is closer to file transfer than RPC.

pshirshov 4y ago
Yes it is. It's a semiformal weak-typed RPC.
- naasking 4y ago
  RPC does not make idempotency guarantees, REST does. Ergo REST is not RPC.
  - pshirshov 4y ago
    > RPC does not make idempotency guarantees Not true. "RPC" is just a generic name and there are multiple approaches and implementations which may provide you some guarantees, in specific environments such guarantees may be strong. > REST does How can I enforce or trust any REST "guarantees"?
LudwigNagasena 4y ago
I don't know what REST is "really" supposed to mean [1], but every time I saw it used, it basically meant RPC with JSON over HTTP. I have just googled a random service that self-describes its API as REST [2]. I would be glad if someone could pinpoint me at the exact differences that make it "closer to file transfer than RPC". [1] I guess in its original long gone meaning it's something closer to what 90s web looked like, but no one uses it in that sense. [2] https://developers.google.com/fit/rest https://developers.google.com/fit/rest
- theamk 4y ago
  Here is an example: https://developers.google.com/fit/rest/v1/datasets#get_a_dataset https://developers.google.com/fit/rest/v1/datasets#get_a_dat... It says: "To get a dataset, do HTTP GET to this URL. The result is a JSON document". Notably, this does not _look_ like RPC call -- there is no "getData" anywhere, no {"status": "ok"} field. Instead, this is pretty identical to how you would access a static directory with weirdly-named files. (If you never worked with "static directory with weirly-named files" API, here is an example: ftp://ftp.swpc.noaa.gov/pub/forecasts/45DF/ . To fetch data, you access file named "{MM}{DD}45DF.txt" (via FTP, no less!), get the document and parse. The REST is a modern equivalent of this.) NotablyThis does not sound like a "getData()" function
  - LudwigNagasena 4y ago
    Even disregarding the argument that those differences wouldn't warrant the asserted distinction, > there is no "getData" anywhere Here it is: HTTP method GET > no {"status": "ok"} field And here it is: "The response is a 200 OK status code."
    - theamk 4y ago
      Under the same logic, would you call fetching static file "RPC call"? What about fetching a static file via FTP (per my other example) or Gopher -- is this RPC as well? In general, do you think it is possible at all to have a request/response protocol which is _not_ RPC?
      - LudwigNagasena 4y ago
        > Under the same logic, would you call fetching static file "RPC call"? What about fetching a static file via FTP (per my other example) or Gopher -- is this RPC as well? Fetching stuff over FTP, Gopher or HTTP is not RPC per se. Just as merely using classes, or not using classes, doesn't mean that you do or don't adhere to OOP. > In general, do you think it is possible at all to have a request/response protocol which is _not_ RPC? RPC means that you call functions that require remote execution similarly to the way you call local functions. If what you are doing doesn't fit that paradigm semantically, it isn't RPC.
- naasking 4y ago
  > I don't know what REST is "really" supposed to mean [1], but every time I saw it used, it basically meant RPC with JSON over HTTP That "basically" is doing a lot of work in your claim. Show me the equivalent of idempotency that clients and servers can depend on in any standard RPC spec. If there is no such guarantee, then REST is not RPC. Certainly you can in some sense mimic REST using RPC per the Turing tarpit, just like you can simulate RPC in REST, but that's not the same as saying REST is RPC.
  - pshirshov 4y ago
    @readonly def readProfile(uid: UserId): UserProfile @total def sum(a: int, b: int): int @pure def traverse(...): I can't enforce any REST "guarantees" but I can do it up to some extent with a custom RPC framework.
  - LudwigNagasena 4y ago
    https://pubs.opengroup.org/onlinepubs/9629399/chap6.htm#tagtcjh_10 https://pubs.opengroup.org/onlinepubs/9629399/chap6.htm#tagt... > With the RPC communications protocols, a maybe call lacks execution guarantees; an idempotent call, including broadcast, guarantees that the data for an RPC is received and processed zero or more times; and an at-most-once call guarantees that the call data is received and processed at most one time (may be executed partially or zero times). Both idempotent and at-most-once services guarantee that a sequence of calls in a session are processed in the order of invocation by the client.
    - deleted 4y ago
      [deleted]

itake 4y ago

REST is an RPC?

peterhunt 4y ago
Not in the eyes of its creator https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert...
- LudwigNagasena 4y ago
  Is there a single example of API that fits that definition of REST though?
  - empthought 4y ago
    HATEOAS is the search term you want to use. “Hypermedia as the engine of application state.” PayPal and GitHub APIs tend to work this way. They return a pile of hyperlinks.
    - LudwigNagasena 4y ago
      If by "tend to work that way" you mean that they satisfy around 20% of the requirements in the post by Roy T. Fielding as opposed to other services that satisfy only 10%...
      - empthought 4y ago
        I don't think you are familiar with the GitHub REST API; none of Fielding's points apply to it.
        LudwigNagasena 4y ago
        I honestly don’t know how someone can design a truly HATEOAS API without breaking everyone’s expectations and making it a chore for people to deal with it. If stuffing a bunch of links into your JSON response is what truly transforms your RPC into REST (I don’t see what else makes GitHub API so different from other APIs), then I don’t even know what’s the point of that. And surely it is only superficially similar to the non-API REST, ie how simple websites usually work.
  - progval 4y ago
    HTTP+HTML+CSS (and Javascript) is the REST API used to communicate between clients (browsers) and servers. It's not a coincidence, it was the point of the thesis defining REST to formalize and improve the Web. See: https://www.ics.uci.edu/~fielding/pubs/dissertation/introduction.htm https://www.ics.uci.edu/~fielding/pubs/dissertation/introduc... In terms of what we think of as an API today, my favorite is SWORD: https://sword.cottagelabs.com https://sword.cottagelabs.com In particular, it does not define any URL scheme, client applications are expected to read links from the XML (for v1 and v2) or JSON (for v3) body.
dboreham 4y ago
Yes. All these interactions are "request message with immediate response message" protocols. Everything else is hand waving and religion.
ako 4y ago
Rest is more like a database: a data/resource model, with a fixed set of operations you can use on this model. RPC is like stored procedures in a database. Some databases implementations only provide access to data through stored procedures, hiding the underlying tables. The first is usually more flexible to the client, he can decide what data it needs. RPC in a database is gives the server more control over the client: what data it can get, how it can be retrieved/manipulated. This introduces tighter coupling between client and server, which can be a problem is you have many unknown 3rd party clients.
- itake 4y ago
  The "data/resource" model also "hides the underlying tables". For example, `POST users/1/emails` might "create" an email, but really its triggering a API call to an external service. I am not seeing the difference between REST and RPC.

linza 4y ago
Not sure if you are more agreeing or disagreeing with GP, but cost is not just computing cost, but also complexity and the higher risk to reliability that comes with it. JSON-RPC makes sense if one only considers the abstract case with a single client and a single server box and minimal networking. Technically it's a viable solution but just not practical. HTTP on the other hand is nice as it separates the business logic stuff like the RPC parameters from stuff that's interesting to the transport-network-thingies that sit between you and the data on a server, like load balancers, DoS protection, authz, rate limiters, ... etc.
- jillesvangurp 4y ago
  It's a trade-off. Mostly pure REST is nicer for external APIs where it's just more important to follow the principle of the least amount of surprise for the ed user. For better or worse, people kind of know how to deal with REST clients. Graphql, SOAP, etc. all force the user into doing complicated stuff with libraries, figuring out parsing for their techstack, etc. This is fine for internal microservices where you might not care too much about this and can standardize things a bit. But for external users it's more challenging. With simple Rpc stacks (like JsonRpc), basically the up side is you get to rely on code generation to deal with networking. Cutting down on the amount of ceremony for adding new stuff is definitely nice in a fast moving team. But I would not use it for external APIs. It's kind of a legacy way of doing thing. An alternative to something called XmlRpc, which used to be a light weight alternative to SOAP when people were still doing XML and when MS came up with the genius idea to stuff something called an XMLHttpRequest in Internet Explorer. This was what enabled Ajax websites early on. The X in ajax of course stands for XML. That was just before json got really popular and people started getting really pedantic about their REST verbs. Anyway, short history lesson. I'd not over think this and indeed simply use REST for public/external APIs and use whatever works for you internally for e.g. client server traffic between your browser/mobile apps and your servers or intra microservice communication. If it's internal, you control the techstack and you can sacrifice some things for making it faster/easier to develop and use without too much regard for what the other side is going to be using. Because you control both sides. REST APIs can be a bit of a burden to maintain. Lots of boiler plate client and server side. Not always the best choice internally.
still_grokking 4y ago
> People used to do SOAP which is all of the downsides of graphql and json rpc combined without most of the benefits. Stupidly complicated to do just about anything with it. To be honest, this looks like cases of "you holding it wrong". SOAP was one of the simplest systems I've ever worked with! You point your client lib to a WSDL and everything else just happens automatically. All you do then is calling regular methods in your code (witch happen to be remote calls). All the network crap is abstracted away and completely hidden. Full transparency. Issues start to come up as soon as people thing they should do SOAP "by hand". Sending hand crafted XML through HTTP libs. This is of course pure horror. But this whole thing was never meant to be used like that. As long as you used the proper tooling SOAP is really great and orders of magnitude more productive than RESTfull nonsense.