Is RPC just ad hoc endpoints? The info on REST is overwhelming, to many different opinions, for a simple SPA do programmers really need a formalized client-server contract? Can one just access server capabilities through ad hoc endpoints and write custom code to fetch the data they need? servers define procedures, and they return data.

I ask because I'm going to start writing my first http api for a small SPA.

It just causes so much busy work. Then busy work leads to bugs, which leads to framework abstractions, which leads to implicit nuance in almost every part of web development.

RPC and client-server contracts, as well as static-typing, is a bloody god send and the whole world will be in a better place once we formalize and accept it (I didn't say standardize I said formalize).

I'll defend REST's utility for simple data retrieval. If I just need a paginated list of comments on a video, being able to quickly hit /video/1093/comments and get that list back is really nice.

More complex use cases, and specifically non-idempotent operations, is where I find REST doesn't hold up as well as RPC.

> If I just need a paginated list of comments on a video, being able to quickly hit /video/1093/comments and get that list back is really nice.

REST isn't about human-readable URLs. The link to the comments should have been part of the representation returned for /video/1093 (typically JSON these days, so a "comments" property of the object).

As ben_jones stated, a client and server need a formalized contract or you're doomed to break things. Whatever you use needs to at a minimum be: - internally consistent - sufficiently documented that a developer on either side understands what the other side does

REST is just a set of rules to follow that attempt to avoid some pitfalls and provide a common parlance.

nothing wrong with a good well documented json rpc over http

the main difference is endpoint negotiation vs object state transfer - consider an account representation - if you can withdraw, the link to perform the withdraw operation is there in the server response. if you can't, the link to the withdraw operation is not there. this is how the returned value convey the object state and how it let client explore object operarions.

say, it's the difference between returning an object instead of a struct, and it's also why json alone is not compatible with rest, there's not an agreed schema to identify operations coming along with the data so that a client can actionit - json-ld and hal can, if you reallyhate the idea of xml tho.

Don't write an API. Use something like reindex.io.

As a shorthand, think of REST as about nouns, and RPC about verbs.

/account/1 is REST because the you're looking for an account (noun), the account id is 1, and you're using the HTTP method GET.

/search/hello is RPC because it uses a specific verb (search) to call a remote procedure to search for the 'hello' keyword. You're taking an action for which there is no appropriate HTTP method, so RPC can be used instead of REST.

This doesn't cover 100% of every situation, but it's useful as a quick mnemonic.

That's incorrect. REST has no such restrictions on URLs. URLs can be completely random numbers with no human-discernible meaning.

REST is about architecture, about where state should live, how long it should live, how messages between entities should designate resources/state, all so you can preserve encapsulation and maximal flexibility for service upgrade. Your service is not RESTful if you don't meet these criteria.

RPC has no such restrictions, which means you're free to do everything wrong, which virtually everyone does, and you'll still be doing RPC correctly.

> /account/1 is REST

Probably not. If "what this is and how it relates to other things" is determined by looking at the URL path and not the media type (for "what it is") and link relationshops (for how it relates to other things) it's not REST.

And that's the issue. Most engineers don't understand HTTP. Just the amount of people who confuse PUT and POST is pretty high. Getting people to remember that media type exists is hard. Add in the rest, it's just not happening.

But the unicorn "properly designed REST api" is quite nice.

Since i can't trust anyone to do it right though, I'll just use GraphQL because its easier to get people to do right.

Reading over your comments, I'm curious what you would consider to be an API that properly implements REST principles according to the original dissertation.

When people mention RPC in this context, are they talking about a generic concept, or are they referring specifically to SOAP? Because SOAP was always a complex mess, pretending that WSDL files somehow added semantic meaning to data, when it fact it was just a serialization format with excessively verbose data typing and validation of element presence/counts. SOAP made even the smallest projects feel like a bloated nightmare typical of "Enterprise bureaucracy". SOAP is the very reason why people eagerly latched onto JSON and REST the moment it became viable.