A few days ago I posted on LinkedIn:

"Unless you have a Google/Meta/Antropic size API problem, I have a simple rule/insight:
Don’t create an api you can’t interact with using curl".

I've been asked to elaborate.

The tool and the task

Firstly a remark about the tool, curl. It is an incredibly powerful tool with super flexible use cases. Just look at the list of supported protocols: DICT, FILE, FTP, FTPS, GOPHER, GOPHERS, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, MQTT, POP3, POP3S, RTMP, RTMPS, RTSP, SCP, SFTP, SMB, SMBS, SMTP, SMTPS, TELNET, TFTP, WS, WSS.

Understanding, even mastering it, is a must have for any developer (or admin for that matter).Want to fetch data unencumbered by CORS or CSP - curl is your friend.

You can read the sentence above also this way: Don't design an API if you. haven't mastered curl

Picking an API architecture is a big decision and there are quite many to pick from:

Here's the markdown source code:

Architecture	Description
REST	Uses HTTP methods to access and change resources through URLs. Robust well supported architecture with mature tooling. Easy to discoverm used for Web services, mobile apps or public APIs. Not suitable for real-time bidirectional communication or data transfer minimalism. Typically uses JSON payloads, previously XML, but will cater any data. Complex queries need to be handled in application logic. Really needs HTTP QUERY
RPC	While REST is resource oriented, RPC is action oriented and is not limited to the HTTP(s) protocol. Typically you have a single endpoint where the posted payload determines the action. Examples are SOAP, JMAP, CORBA or propriarty protcols like in use with React Server Components
GraphQL	Client requests exactly the data it needs using a query language, used in apps needing flexible data fetching, reducing over-fetching. Since the Query is clientside complexity is shifted to the client and security can be a nightmare. Sucks for caching or file uploads. Microsoft is a fan
SOAP (Simple Object Access Protocol)	XML-based protocol with strict standards and built-in error handling. Unparalled accurate through WSDL definitions. Works well between unrelated parties, e.g. ebXML, heavy protocol, not popular in web applications anymore (despite giving AJAX its name)
gRPC (Google Remote Procedure Call)	High-performance framework using Protocol Buffers. The data definitions are not transfered, like in XML or JSON, so data transfer is minimized, can transfer bucket loads of data. When you run trillions of requests, like Google, every bit counts. Severe limitation on discoverability, language support and tooling. Best used server to server
WebSocket	Two-way communication channel over a single TCP connection used for Chat apps, live updates, real-time gaming, scaling is not for the faint of heart
Webhook	Server sends automatic HTTP callbacks when events occur. Basically two way REST. Elegant and hard to test unless you can control the callback destination. Popular for payment notifications, automated workflows, CI/CD pipelines. Has special needs to make it traceable, no guaranteed delivery or real-time two-way communication
MQ (Message Queue) or MQTT (Message Queuing Telemetry Transport)	Publish/subscribe messaging protocols, MQTT is suitable for low-bandwidth networks. Asynchronus processing of requests for loosely coupled systems. Very flexible but its store and forward principles require careful planning, especially around security and replay (keyword Idempotency)
Kafka	Distributed streaming platform that handles high-volume data streams. In laymen's terms: a queue like MQ, with added transformation capabilities, persisten queue storage, suitable for really big volumes of data (just ask Uber about it). Fun to use, not fun to run (strongly advise hosted Kafka). Kafka is the big gun, it can solve your problem, in a lot of case like a shipping container can deliver a single pizza

Looking at the options (I'm sure there are more), you can see which ones can be covered by curl: REST, some RPC (when HTTP or SMTP based), GraphQL, SOAP, WebSocket, Webhooks (only to initialize). Eventually Kafka, when its http interface is active, but that's just http based RPC.

Compare the "Command Line Pain"™ when using curl to model a request (or process the result with jq). This gives you a data point you can add to your considerations which API to implement. It shouldn't be the only one: complexity, environment, data volumes, security etc. are equally important. The curl exercise helps to keep an eye on the tendency to overengineer.

As usual YMMV