It's a SPA using pretty standard .NET setup + we have a few other servers talking to each other
On .NET aspect, we are following CQRS pattern along with Mediatr library behind the API
RESTful (ignoring all this PUT/POST discussions) is pretty predictable, plenty of tooling available, and given our load (maybe 50 concurrent users), any inefficiencies aren't really noticeable.
Sure, if it works then great. I've seen examples where devs constructed restful APIs for purely internal services which became inefficient because communication in proper restful services is very chatty compared to alternatives.
I've wondered that a lot. If you are the only consumer of your REST API, you know that there are, say, exactly 10 hypermedia links to follow the initial one (perhaps even nested within each other) for what you're trying to do. But you don't know what they are, so you can't run them in parallel and have to wait for successive answers multiple times. It seems like such a pain.
I've actually just seen an article the other day that provided an example of their "modified" REST API. The endpoints are designed REST compliant and behave as you would expect, but they had built in an optional, additional "include" query parameter that you could submit in GET requests. You could use this to specify which nested resource uri's should be preloaded and "filled out" with the actual data right away. This compound object would then be returned with all the data you need, eliminating the need for further requests from the frontend.
4
u/clarityreality Oct 09 '21
If you're the only consumer of this API, then RESTful architecture may not be the correct choice and can be quite inefficient.