SQL is mainly four verbs, select, insert, update and delete. Not awkward.

Four verbs are enough if your intention is to implement REST. If what you are implementing is RPC I can understand why you get annoyed. REST was never intended as basis of ALL communication, but the IT world seems sometimes bent to exploit an idea well beyond its limits.

If your domain is built with all nouns as a core part of what it inherently already is (like a Database being built on "records" or "documents"), then a RESTful interface for it "might" be workable, with the limited CRUD verbs.

However, a vast number of web developers (dare I say "most") became convinced the proper way to "think" about their architecture was "as if it were all nouns" (even when it obviously wasn't), because they thought they were having an "epiphany" about how to use REST

...when what they were really doing was conforming to software development "meme" (or trend)

> However, a vast number of web developers (dare I say "most") became convinced the proper way to "think" about their architecture was "as if it were all nouns" (even when it obviously wasn't), because they thought they were having an "epiphany" about how to use REST

I don't think "developers thinking their architecture was 'as if it were all nouns'" is somehow limited to REST or even web APIs. It's a fundamental part of objected oriented design philosophy.

http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...

I think a conversation between a web browser (SPA RPC) and a back-end server is best thought of as an RPC. Procedure calls are verbs if you ask me.

Here's my own code that is such an API:

https://github.com/Clay-Ferguson/quantizr/blob/master/src/ma...

You can point out that 80% of those API methods are resulting in some kind of CRUD method, and I'd agree, but nonetheless trying to make it a true REST API would be super awkward and verbose, imo, because lots of those functions result in multiple CRUD ops on multiple different types of data.

When I design an API, I think: "What is this operation called? What data is best to send upstream, and what do I want to get back." Then I design the API. The API is a wrapper around an abstraction layer of functionality. REST is all about removing that abstraction layer which is moronic.

This is all a matter of definitions. For example, from a syntactic point of view, Java has three verbs for all objects: "instantiate (new)", "call method" and "access field". An object has members, and you can use those 3 verbs to interact with the members of the object.

In my experience, the nice part about designing APIs in a REST-like manner is that they encourage you to think in terms of observable operations. For example, instead of "calling" a long running blocking method, you create a resource that represents the long running operation, and now you can check its status while it is running, report progress, cancel it.

Basically, when designing a REST API you think about the exact same things you are saying - what is the operation called? what data does it need, and what does it return? - and then you represent this as a resource that can be created with the right input, and that will point to a result resource for the final output.

For example, my usual pattern for things outside of CRUD is something like this:

--> POST .../operations/renderNode {ExecuteNodeRequest goes here}

<-- 202 Accepted Location: .../operations/renderNode/891

--> GET .../operations/renderNode/891

<-- 200 OK {status: IN_PROGRESS, percentage: 78, ... (includes initial ExecuteNodeRequest params)}

--> GET .../operations/renderNode/891

<-- 200 OK {status: SUCCESSFUL, percentage: 100, resultURL: .../operations/renderNode/891/result, ...}

And then on GET .../operations/renderNode/891/result, you have the final result.

Of course, if the operation finishes quickly enough, any of the polling steps can be omitted - e.g. it can directly return 200 OK and the result URL for the initial request. If you have WebSockets support, you can also be notified via WebSockets when execution finishes, instead of polling.

It may look like more ceremony, but in general, for long running operations that will be called from a browser, this kind of approach is a requirement anyway, since the number of connections with a particular origin is extremely limited.

Note that I also think your API would be much more concise as a REST API, since all of the miriad "setX", "getX", "createY" methods would be reduced to a few resources with multiple fields, that you can simply GET to see all fields, or PATCH to change a single field (or even change multiple fields in a single request).

I agree about creating some kind of "context object" that represents the status of a long running report, that exists for the duration of the report and can be checked later. It's a very common pattern I've used a lot myself.

Where REST makes that awkward is that many "verbs" I want to use in my API result in multiple such objects being created on a server, and multiple objects being returned (in some wrapper class), and that's awkward with REST because REST is all about making those nouns directly accessible. I don't want that. I want a vocabulary of actions. My client "does things". Doing is a verb. Verbs operate on nouns. The nouns will all exist but they themselves aren't the API.

My other gripe is that I don't want the tech stack dictating to me ahead of time what my verbs are. Some of my verbs might do a create, and update, and some deletes, all in one verb as part of a transaction. There's no such thing as "Is this a create or an update or a delete API call?" It might be all those simultaneously.

Each API call should have a unique Request object and and Response object. When your request/response are specific verbs, you can then later rename the verbs and easily add additional info to the Request and/or the Response without redesigning all your objects. Objects should be designed to model the data itself and NOT have any direct relationship to the API. Objects are in the language of the API verbs, but they don't control it.

The goal of REST isn't to be the RPC protocol. It is to be lower level protocol which uses simple verbs to transfer state.

For example, SQL has simple verbs because it doesn't want to know what are the actual operations executed by the application (for example, verifying status of an existing process, checking optimisting lock, etc.)

Another example are some remote memory interfaces which basically transfer blocks of memory back and forth without knowing what is the operation for. You build your higher level, business logic-aware protocol on top of it.

The same way, REST is about intentionally not getting involved with the imperative style and instead provide transport protocol that will make it possible to refer to the things as resources, discover resource graph through hyperlinks, etc.

The business logic is supposed to introduce changes to the object but use REST to only transfer representation of the changed state (Representational State Transfer) without burdening it with RPC details.

That is why so many APIs fail to use REST effectively, because designers do not understand the goal and limitations of REST. It is conscious decision not only what the API does but also what it is not supposed to do.

To update the user the REST-ful way would be to allow the client to fetch the user document, introduce changes client side with whatever logic the client wants and then transfer the representation of modified state back to the server with a simple verb (same way we interact with filesystem through reads and writes without kernel ever knowing what this is). The server decides what to do with these changes.

Trying to burden the kernel with information about what the operation is is futile but that's what usually happens when people design "REST"-ful APIs.

> The goal of REST isn't to be the RPC protocol

I'd politely disagree with that. I think most REST fanatics ACTUALLY DO claim that their beautiful arrangement of nouns and their 4 CRUD verbs are capable of replacing RPC, because they've become convinced the "procedure" part of RPC, means that RPC is inherently built around functional programming which is verbs, and they think they've found a better way than using a custom vocabulary of verbs.

So they're using REST instead of RPC, because "verbs are bad".

I'll just restate my opinion that the concepts of "functional programming" are not somehow rendered obsolete whenever the machine you're talking to happens to be remote. Sure, there are certain challenges involved with designing a 'remote' API that can arise involving latency and bandwidth considerations, but those limitations in no way imply a solution where you throw out your entire set of "verbs", like REST does.

I think that REST is the language of your API. Just like in a regular PL you normally have just a handful of verbs, as I said in my first answer, so to in REST you only need a few verbs.

Of course, you then build up functionality over those base verbs, just like in a program. But your programming language doesn't have a verb for each function you might want to write. It just has the base 'call' verb.

I've said everything I know to say, 10 different ways all over this thread. It's a topic lots of people have strong opinions about for sure.

This used to be bother me a fair bit, but I learned to noun a lot of the verbs I wanted to use. You don't sell, you create a sale. You don't move, make a movement.

Right. So you bought into it, sounds like. Almost every other software developer did too. They all think they had an epiphany. They didn't.

As for me, for 30 years I've known software function calls are inherently verbs and I'm not gonna let a trending "meme" (like REST) convince me otherwise. haha.

I mean it's not so much the "nouning" of verbs that's the problem, but it's the loss of the ability to use verbs that I find so appalling.

I mean if I need to run some reports it had better be called "runReports()" not some janky update of a state of some 'report' object to change it to 'running' state. So silly. REST is so jank.

I mean what if "runReports()" needs to start N number of independent reports and return the status of startup of each one. With REST you always end up fighting things like that which are totally trivially easy without the REST nonsense.

Creating nouns out of your RPC is actually powerful and transformative. Verbs are transitive but nouns can be queried, handled asynchronously etc.

It feels like jumping through hoops but you end up with a more solid API for the web.

I like code that's simple to understand like this:

``` let user = api.getUser(); user.setName("Clay"); api.saveUser(user); ```

That's just a basic RPC API. No one will ever convince me that turning all that into some kind of noun-based equivalent is better.

The fact that a GET and a POST are HTTP verbs that match up to that is is meaningless to me because I could care less about the HTTP layer in my API design. APIs should be decoupled from all underlying architecture as much as possible. REST is about TIGHTLY COUPLING THEM as much as possible. Bad idea.

> No one will ever convince me

Well for anyone else listening, a RESTful design would help you know whether you're creating or updating a user. You would know if you're allowed to repeat the request without side effects. That's useful in a distributed api where half open requests are inevitable.

I think with functional programming developers are capable of knowing whether they're creating or updating a user.

However with REST I can't "transmogrify" a user. Do you know what a "transmogrification" is? No you don't. Because REST doesn't do that. It's a domain specific verb I made up.

To force REST to work you'd have to invent a new noun called "transmogrify state", even if no one would have ever conceived of that state in a functional programming design. Whenever you end up inventing new objects specifically to work around architectural limitations, that's not a simplification. :)

Functional Programming works. Nothing invalidates verbs just because you're doing them over HTTP, for example. Your API design should have no clue if it's running over HTTP or something else.

You're right. No one knows what rules apply to transmogrification. That's why people use the http verbs to consistently create and edit things without having to look up the caching and idempotency rules of every random thing your API does.

If your API had a /transmogrification/<id> resource. I would know how to query its state and possibly edit it. I have a clear place to look for previous transmogrifications without crating a new one and I even have a nice query syntax support.

Or maybe you don't support GET and return a 405 response. That's ok too.

You basically just explained how REST works. :)

* Limits number of verbs to CRUD ones (HTTP).

* Makes every verb into a noun.

* Tightly couples HTTP-codes into your API.

* Requires creation of many endpoints you don't really need.

* Makes it awkward to have a single request that updates multiple different types of objects, or queries different types of data.

yeah, I don't want any of the above in my life.

> The fact that a GET and a POST are HTTP verbs that match up to that is is meaningless to me because I could care less about the HTTP layer in my API design.

REST is a protocol-neutral architectural pattern, so, yes, you should care less about the specific protocol and it's verbs. REST is about resource representation (the nouns and the ways they are represented as data) driving everything, not wire protocol verbs. HTTP is itself a REST API built on top of TCP/IP, but other REST APIs don't have to be built on top of HTTP, or even tied to a single underlying protocol.

> APIs should be decoupled from all underlying architecture as much as possible. REST is about TIGHTLY COUPLING THEM as much as possible.

No, it's not, even approximately.

If REST is "not even approximately" coupled to HTTP, then how do you explain that people attempt to use the fixed set of CRUD-type of verbs (GET, POST, etc.)? Just a coincidence I guess. lol.

> If REST is "not even approximately" coupled to HTTP, then how do you explain that people attempt to use the fixed set of CRUD-type of verbs (GET, POST, etc.)?

REST over HTTP uses standard HTTP methods with their HTTP-defined semantics rather than unnecessary ad hoc, API-specific extensions because, well, first, why would you do anything else if you want to use a standardized underlying protocol? And second because: “A REST API should not contain any changes to the communication protocols aside from filling-out or fixing the details of underspecified bits of standard protocols, [...]” https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert...

I consider HTTP the 'pipe' over which the data is marshalled. It has it's own error codes, it's own verbs, and it's own protocol that has nothing whatsoever to do with my API for my APP and that's the way I want to keep it.

I do an HTTP "post" to send up a JSON object as a request, and I get a JSON object back as the reply. No one is going to tell me there's a "simpler" way. There isn't.

For example, if I need to delete data, I'll call "deleteSomething" as an endpoint. I could care less if HTTP has a delete in it's language, because I don't want/need any of that coupled into my API or affecting my API in any way whatsoever.

That way my API can be moved to some non-HTTP pipe at some point and it will remain unchanged. It's just like how in good OOP you ideally code to 'interfaces' rather than coding to 'objects' directly.

Here's an example controller: https://github.com/Clay-Ferguson/quantizr/blob/master/src/ma...

You can tell it's perfectly type-safe on both client (TypeScript) and server (Java), and the API itself doesn't have any clue it's even be running over HTTP, and that's a good thing.

I'm not sure what your point is. Yes, RPC over HTTP post is a perfectly valid style of API. It's not REST. It may in some sense be simpler, but being simple for a narrow interface isn't the hallmark of REST (being simple on an “across a whole world wide network of diverse resources that don't share common ownership and control” is more REST’s thing.)

My entire discussion has been around the assumption that there's some very specific WebApp that needs to communicate to a server (likely over HTTP too), and that I like RPC and verbs in my API.

What you seem to be stating is that there's more to that on the web and that HTTP has a reason to exist. I agree. It makes sense for the language of the browser itself to be basic CRUD-type calls to servers (which is what HTTP is)

But for a specific RPC interface for a specific WebApp client, trying to meld THAT API into HTTP (the goal of REST) is awkward as all hell and that IS what everyone's using it for.

I think that's a bad example, because it almost perfectly matches up with REST.

user = UserApi.get(id)

user.name = "Clay"

UserApi.put(user)

Does using put instead of save really bother you that much?

The tight coupling doesn't matter if you are building a web service. HTTP is how they work.

What bothers me is that if I have a verb called "transmogrify" in my API's domain language the REST purists will try to tell me not to use that verb, because some preexisting generic CRUD-type verb can be made to work instead. Sorry, no, that's awkward.

>I mean if I need to run some reports it had better be called "runReports()" not some janky update of a state of some 'report' object to change it to 'running' state. So silly. REST is so jank.

I fail to see how that's janky, it sounds like a great abstraction. I would have a 'createReports()' method that returns an array of Report objects that all correspond to a record in a database. Easy to query for the state, id, or any other details I might need. Doesn't get any cleaner than that in my opinion.

Yes, we agree. What I meant is I'd have a verb that creates and returns some kind of "ReportContext" object, which sends back an "id" which I can then query status of later, for example. But no REST.

My point is that the entire endpoint would be mostly verbs (like runReports) and use only the HTTP POST to communicate. So I'm "ignoring" the fact that it's running over HTTP, I would ignore every "rule" of REST, because REST offers nothing but hurdles to jump over.

I didn't really have an epiphany or buy in, I just figured out a way to think about it so I wasn't worrying about verbs all of the time. Purity in all things is a problem, REST included.

One thing that kind of gets you is that HTTP itself is not the best transport for all of these things. If we are talking about something that has to run over HTTP, we might do something like create a run of reports (maybe a POST to reports/run). That could return a list of report_ids that were created and their associated status, with an run_id associated with the collect run. There's no fighting!

However, if you want that data streaming back to you, this is where you might think you want something more like WebSockets. For some use cases, this can be more efficient than having the client polling to see if the result of a long running process is ready. It all depends.

Anyway, not advocating for anything here, just pointing out that I had the same worry about supporting a rich vocabulary of verbs, but then kind of realized it didn't matter because all verbs you want can be nouns. If you are using HTTP though, the REST verbs match up pretty nicely with how the protocol works, so it avoids inventing another abstraction to sit on top of it.

You seem to realize that an RPC API design is totally separate concern from HTTP, and I agree with most of what you're saying, but then in your last sentence you say "REST verbs match up nicely" and can simplify your API. Respectfully, no it can't.

REST doesn't remove abstraction layers, it creates abstraction layers. Whether you do REST or not you will have an interface between client and server, which has to be documented and have a well defined set of nouns and verbs, period. Can't be avoided. Removing my choice of verbs does NOT simplify things. If my API only needs CRUD verbs that's what I'll use. No problem. But forcing me into those 4 verbs, only, ever, and always (as pure REST does) is not a help, it's a hindrance.

By "REST verbs match up nicely", I meant REST verbs match up nicely with HTTP methods...(there are currently about 9 HTTP methods?). That's why it's not an additional abstraction, a POST is a POST. Compared to SOAP, which is where I came to it, it's tightly aligned with the transport. (People used to advocate for SOAP saying you could use it over SMTP...). If you are going to do a non-HTTP API, REST doesn't make a lot of sense.

Anyway, I was still annoyed by the limited verbs 10 years ago after using REST for five years at that point. I even blogged about it, as I started doing HATEOAS about that time, so I really feel your annoyance. I've just discovered over time that the verb/noun thing is just stylistic, not an actual technical concern. All of your verbs can be nouns.

I've also done plenty of SOAP back in the day. I independently invented the equivalent of SOAP in an API back in 1998 where my RPC API used only one method, which was basically a "call(command)" for sending XML data upstream and getting an XML response (C++ app). The request XML had the "name" of the "verb" as part of the request. Basically a "command pattern".

So what I do today is I use "REST APIs" (like in Java Spring, Axios/Ajax, etc.) but all my endpoints are named as "verbs" (not nouns), and the only HTTP verb I ever do is a "POST".

So everything boils down to this:

let myJsonReponse = api.doSomeVerb(myJsonRequest);

Your comment illustrates how REST forces you towards an OOP-style: https://steve-yegge.blogspot.com/2006/03/execution-in-kingdo...

Sure you can definitely create an OOP-style architecture that allows only 4 functions to exist on any object (create, read, update, delete)

Programmers have had the ability to do that since the 1960s and guess what... nobody ever wanted to do it.

With the advent of HTTP (and it's fixed set of verbs and return codes), that didn't somehow invalidate all the prior decades of OOP. lol. However RESTful fanboys disagree with me on that.

You can have as many verbs as you want, but they all need to be valid at every state of the application (i.e at every hypermedia target), because you still want a uniform interface.

Responding with a standard error code is okay for verbs that are not supported at a particular state, but it's the uniform interface constraint that forces you to keep the set of verbs small.

Also, HTTP has nine verbs: GET, POST, PUT, DELETE, HEAD, CONNECT, OPTIONS, PATCH, and TRACE.

You can read most any good book on software development and API design, and OOP, and how to create good abstraction layers, and how to name functions, and pass parameters etc.

Here's the thing: None of those concepts in those books are trumped once you happen to be communicating over HTTP/HTTPS. None of those books tell you to come up with 9 verbs, and make everything a noun operated on by those 9. That's silly.

HTTP layer has a place in the tech stack. Let it do what it does. Your API RPC layer is a separate abstraction layer, that also needs to exist. Trying to merge RPC down into the HTTP layer is silly and is cramming a square peg into a round hole, just because the round hole already existed.

My experience is that the design considerations within a system are different from the design considerations between systems. Specifically, noun-oriented APIs with few generic verbs tend to be extremely effective at:

1) Being relatively fast for external developers to come up to speed with

2) Allowing (and in fact pressuring) you to make non-breaking evolutions to your API without it devolving into a total mess of confusing semi-overlapping operations

3) (As a result of the other two) Minimizing the bidirectional communication needed between groups of developers

The major con is that they tend to require quite a bit more work and code to implement than operation-oriented APIs, especially when you are the only client.

Others will certainly have different opinions, but the view I've been forming over the last few years is that resource-oriented (noun-oriented) APIs should be considered the default for "external" interfaces, while operation-oriented APIs are much better-suited for "internal" interfaces. Do note that, in this model, deciding what is "internal" vs "external" should be an active design choice. It should be made based on your expectations for code ownership/control, communication frequency, and project structure.

One of the reasons Amazon was successful as a cloud hosting company, and offers all the services it does is because of the famous Bezos email/memo to the entire company saying every API has to be designed as if it were external facing (usable by 3rd parties).

I think what you are conflating is "good documentation" and "well designed APIs" as an attribute of REST, when it's really just an attribute of good engineering.

Engineers have used functional interfaces for decades and there's just nothing at all in REST that's any kind of improvement over functional. There's a reason "functional programming" is a thing and "nounical programming" isn't even a word.

“Nounical programming” is only not a word because it’s called “object-oriented” instead.

And we also agree all objects (in OOP) are operated on by verbs (methods), but REST claims that using a predefined set of generic verbs is good. It isn't good.

Pick up any book on OOP and try to convert all the "operations" (method calls) in the book into CRUD methods for every code example in the book. It's doable from an information theoretic standpoint, but the book would become a completely unreadable clusterfk, for precisely the same reason that REST is so awkward. Doing an API with a predefined set of generic verbs is just silly.

In response to the criticism of "noun-oriented" programming, check our this video: https://www.youtube.com/watch?v=BDPHfRuAFnU&feature=youtu.be....

It's worth watching from the beginning, but I've linked to the relevant timestamp (8:30).

HTTP is one particular implementation of REST that happens to have nine verbs. Another implementation might only have two or three. But no RESTful architecture will have much more than nine.

Why?

Because your application is going to have thousands of nominal states, and each one is going to need to support all of the verbs because of the uniform interface constraint.

Why a uniform interface?

A lot to say about this, but basically, the set of verbs is an abstraction of the state machine that is your application. If you have a million states and a million verbs, then you have no abstraction. If you have ten states and a hundred verbs then you have too much abstraction (i.e. you ran afoul of YAGNI). A good degree abstraction is somewhere in between, but if you care about scale (which is the raison d'être for REST), then the size of set of verbs is going to have a logarithmic relation to the size of the set of nominal states.

Most applications will have more "states" than there are molecules in the known universe. Number of states is meaningless, and doesn't play into anything.

If I need to delete users I want a function called "deleteUser" (for example) and it will use an HTTP post to send up info, and it will stream back the response. Period, full stop.

An HTTP "post" is your 'backbone'. Nothing else about HTTP needs to creep into your actual domain specific API language of method names in your RPC vocabulary of verbs.

Also if non-HTTP REST can exist, that's fine, but I'm writing web apps so I will be doing HTTP-posts because, as Fielding himself would say, why redesign something that works.

I didn't say "states", I said "nominal states". These are the states that you would bother to name. They'll correspond to classes in an OOP language or discriminated unions in an ML-stye FP language.

Using your example, you'd have two states: `PrepareDeleteUser` and `DeleteUser` where the latter is only reachable from the former. PrepareDeleteUser will check that the all preconditions are satisfied (e.g. that the current operator has permission to delete the user). Now, you may not choose to reify these states so directly (i.e. you'll just have a deleteUser function that does a check for the preconditions), but they must exist in a robust application nonetheless.

In REST we name our states so we can drive the state machine by using the names (following hyperlinks). Why? Because, among other things, this keeps the client decoupled from the server by letting the client be in control of when to effect a state transition, but keeps the server in charge of what transitions are possible.

I need to attend to some real-life concerns at the moment, but I hope to get back to this discussion soon.

Cheers!

There's nothing wrong with having a "PrepareDeleteUser" to pre-check if a user can be deleted. That's a legit design that you mention, but that does't validate these two silly criteria built into REST:

1) Everything is a noun. 2) You have a finite set of pre-defined verbs.

In my opinion, everything is not noun, and I don't want any verbs pre-defined by the stack.

I will always continue to use HTTP POST as the 'transport mechanism' to send a JSON request up and get a JSON response back. It's the simple and obvious way to do things, and after fully understanding REST (trust me I do get it, fully) my opinions remain unchanged.

There's a reason "functional programming" model dominates all software architectures, while state machines are rarely used in API design. All of the reasons functional programming is good on the same machine STILL APPLY even if the machine you're calling is remote.

And just because you're riding on top of HTTP over the web is no reason to intermingle your application layer code into HTTP-related stuff. Your API should remain unchanged even if HTTP were replaced by something else. Nothing about HTTP should affect one single verb or noun (function or object) in your entire application API...and if it does it's because you've been brainwashed by the REST cult. :)

> A lot to say about this

I'd like to read more about this way of thinking about it. Do you have any recommended resources?

Most of what I have to say comes from Fielding’s dissertation, along with spending the past several years trying to take it as seriously as possible. Other good sources are McCarthy’s Situation Calculus and all of the stuff that Lamport has written on on TLA+ (especially Specifying Systems[1]).

The big idea behind scalability (IMO) is that we want the pain of maintaining a system to grow logarithmically with respect to the size of the system. Now, size can mean many things (number of customers, lines of code, etc.), but pain is almost always complexity. A potent cure for complexity is symmetry, because every time that we discover a new symmetry, half of the complexity goes away. One way of finding symmetry is to look for invariants.

Roughly speaking (very roughly), having lots of possible states is good (the more states, the more powerful/featureful the system), but having lots of state transitions is bad (especially with respect to security). REST “verbs” help to control complexity by imposing invariants on state transitions. For instance, one good invariant to enforce is that a GET transition mean that a state can always be a start state, whereas a POST must always have an antecedent state. Thus, a REST verb is just label for a set of invariants, and we’re free to choose whatever set of invariants we want. Obviously, the more invariants you have, the weaker they are since an invariant is supposed to be unchanging; i.e. if the size of set of invariants is close to the size of the set of states, then you effectively have no invariants.

[1] https://lamport.azurewebsites.net/tla/book-02-08-08.pdf

> Also, HTTP has nine verbs

http://webconcepts.info/concepts/http-method/

Right, I simplify REST it as a CRUD model, because nobody ever uses the full 9 verbs in REST architectures anyway.

My who point is that having a fixed set of verbs is about as awkward as it gets in software design, even if there were 100 to choose from.

IMAP has many more verbs compared to HTTP, so wouldn't it be a better application layer protocol compared to HTTP for a REST API?

REST doesn't care about the size of the set of verbs, only that the set be constant. HTTP as one particular implementation of REST just happens to have nine verbs.

I tried to implement an IMAP server a few years ago, but otherwise I don't know much about it. However, I do recall that Mark Crispin admitted that he wasn't a very good API designer, and that much of the complexity of IMAP was due to it being intertwined with the complexity of MIME. But, I can't find the sources for those claims at the moment.

For normal SPA JavaScript/TypeScript browser-based apps, I like the conventional approach of an HTTP "post" for every API call. You send JSON upstream and you get a JSON response back. Basically it's an Ajax call that gets data back to use to update the page.

Agreed! A SPA using an RPC API usually makes the most sense. I've wasted so much time over my career trying to jam functional concepts into REST resources for little gain.

I really like the idea of each app getting it's own specialized backend. Have you heard of the BFF pattern?

https://philcalcado.com/2019/07/12/some_thoughts_graphql_bff...

I just read that entire article. Thanks for posting that. I like everything it's saying, and it points out some of the major drawbacks of REST.

I've never used GraphQL yet but I know I do like it. Most of what I've done has been a mix of OSFA and BFF. RPC API design is more art than science, but definitely everything about REST is wrongheaded, inside out, upside down, and ass backwards. lol.

True REST API is hypermedia API and it is actually great for SPAs. It is more convenient than hardwired RPC, simplifies frontend architecture and offers much better approach to security (client does not care about security model implemented on server).