8 ms·

REST APIS suck for nested resources. GraphQL is a huge breakthrough in managing them. Ever seen an engineer do a loop and make n+1 REST calls for resources? It

REST APIS suck for nested resources. GraphQL is a huge breakthrough in managing them. Ever seen an engineer do a loop and make n+1 REST calls for resources? It happens more often then you think because they don't want to have to create a backend ticket to add related resources to a call. With internal REST for companies I have seen so many single page specific endpoints. Gross. > There have been different opinions about structuring REST calls but those aren't going to cause any real forward progress for the industry and are inconsequential when it comes to business outcomes. You could argue almost any tech solution in a non-pure tech play is largely in consequentially as long as the end goal of the org is met, but managing REST APIS were a huge point of friction at past companies. Either it goes through a long review process to make sure things are structured "right" (ie lots of opinions that nobody can sync on) or people just throw up rest endpoints willynilly until you have no idea what to use. GraphQL is essentially the "Black" for Python Syntax but for Web APIs. Ever seen engineers fight over spaces vs tabs, 8 vs 4 spaces, whether a space before a colon? those fights happened a lot and then `black` came out and standardized it so there was nothing to fight over. GraphqL makes things very clear and standard, but can't please everyone.

ComputerGuru 2y ago
> With internal REST for companies I have seen so many single page specific endpoints. Gross. Hardly gross. It is what it is and it’s universal across the domain. I bet Windows has internal APIs or even external ones that were created just for one page/widget/dialog of one app. It’s the nature of things at times.
- hansonkd 2y ago
  Its gross because it is a waste. An engineer had to spend time to make that specific API for that page instead of the frontend consumer using what was already defined and get all the resources with one call and 0 backend engineer needed for that new page.
  - clintonb11 2y ago
    Is the flexibility worth the tradeoffs? Maybe in a company where you are adding new pages all the time with deeply nested relational data needs. But I would argue this is more rare than not. And I often find that frontend engineers aren’t as familiar with database queries and the load they are putting on the system with some of the graphql queries they are making. Flexibility for frontend has its own tradeoffs and I totally understand why a frontend engineer doesn’t want to have to wait for an endpoint to be finished. But this article outlines some of the issues you encounter later as you scale your team and system. We use a schema first design where I am at and if a frontend person needs a new endpoint because the resource-only endpoints aren’t enough then they submit a pull request to the schema repo with a design for their endpoint they need. It gets approved and boilerplate is auto generated. Yes you have to wait longer, but 90% of the time (for our software) the resource endpoints work great.
    - hansonkd 2y ago
      Sorry what are the tradeoffs? I'm not sure where this narrative comes from that GraphQL immediately means that the frontend time will have no idea what they are doing and will induce load on the system. 95% of my nested graphql fields are based on foreign key indexes so its almost no additional load to the system (only 1 query per "level" of GraphQL) to query the nested objects. I restrict GraphQL to 5 levels and now I have 5 queries per API call instead of 5 Queries over 5 API calls. The backend team exposes the fields that they know are efficient to query. They can restrict the depth of the GraphQL, number of fields, etc.
  - pavel_lishin 2y ago
    On the other hand, it may take that engineer less time to create a page-specific endpoint than it would be to create something more generic that might serve other purposes (that may never come to pass), which may also involve talking to other teams, checking what future plans are, etc. And that's assuming it's a new endpoint; if there's an existing endpoint that does almost what's necessary, they may need to check in with that team about what modifications to the endpoint would be acceptable, etc. Single-page endpoints aren't great, but often times they're acceptable because they end up being a half-day task instead of a week-long slog.
- datavirtue 2y ago
  It's analogous to a specific method in code. No idea why people go nuts over this.
  - hansonkd 2y ago
    A REST endpoint can be analogous to a specific method in code. just as much as a GraphQL field. What people are excited about is that the frontend can request all the data it needs at once and the backend can efficiently serve it. Something not possible with REST without reimplementing something similar to GraphQL.
    - RussianCow 2y ago
      It's definitely possible, just not without tight coordination between frontend and backend. When your development teams are broken into silos with strong separation, this isn't feasible and GraphQL starts to make some sense. Otherwise, you just create an ad hoc endpoint that serves the exact data you need and call it a day.
  - arp242 2y ago
    Some people treat codebases as an art project rather than engineering project. I think this explains about three quarters of all engineering problems I've seen in corporate context, give or take.
  - svieira 2y ago
    I suspect that people don't think about it too hard and presume that they should have only one model - that is that their REST model should map directly to their DB model which should map directly to their internal domain model (the idea that there might be two-or-more-domains and not-all-of-them-are-public hasn't even yet crossed their minds). When you realize that sometimes your REST model may be a view-model that maps to a different storage model optimized for online-transaction-processing, neither of which map to your internal domain model directly (there are adapters for that) _then_ you get somewhere ... but of course you then have to fight off the `transformToRestModel(transformToDomainModel(retrieveDbModel(theId)))` when the three models happily coincide for a time.
kiney 2y ago
Unpopular opinion: I'm actually a fan of singe page specific endpoints. You get much easier debugging, easier to audit security, easier performance optimization an the imho pretty small price to pay is that it's "not elegant" and a bit of backend code
- shados 2y ago
  The backend for frontend pattern. Something most apps where frontend and backend are in the same organization (fullstack or otherwise) should have. It does wonder to maintainability and performance. Even though we use GQL here, we still have a B4F, so it's browser -> B4F -> GQL -> Database. The tooling we use make it trivial so it doesn't add any development overhead (often reduces it. No CORS bullshit for one), and our app goes ZOOOOOOM.
- nurple 2y ago
  I think it's elegant. I loved MVVM in the postback world, and with SPAs, I see view-specific endpoints as the view-model continuing to reside on the server while the view was split off to the client-side.
- datavirtue 2y ago
  Agreed. Specific endpoints. I was on a project recently where a 40+ yr old dev was going crazy over "pure REST." It's embarrassing. Sure, have your pure REST but FFS create specific endpoints if you they make sense.
  - mgkimsal 2y ago
    You are literally Transferring the REpresented State of a given page/view/screen. Screen-specific REST endpoints will make their way as a default in to a JS-based framework in 2025 and people will pretend like this is some breakthrough advancement.
    - mjburgess 2y ago
      And finally HyperText will progress into the futuristic HyperCard
theptip 2y ago
The canonical REST solution of query params to add nested fields gets you quite far: GET /myresource?extra=foo,bar sure you over fetch a bit if you have multiple accessors. But agreed, if you have highly nested data especially when accessed with multiple different query purposes then REST might not be the best fit. I think GraphQL has been positioned as a general purpose tool and for that I am with the author, REST is a better go-to for most usecases.
- hansonkd 2y ago
  I guess depending on the context of a simple app one level could be viewed as far. Any more levels and you have now reinvented GraphQL
  - WorldMaker 2y ago
    OData existed before GraphQL in the wild, it's possible to suggest GraphQL reinvented OData. https://www.odata.org/ https://www.odata.org/
    - hansonkd 2y ago
      The point is GQL is currently the standard for querying dynamic nested data shapes not that it is the first or was the first. Look at OData download stats on Pypi it had 2 downlaods the last day. Graphql-core for python? 624,201. that is not even on the same planet. If you don't use GQL and want a system of querying nested data you will be using a less used protocol that is analogous to GQL so you might as well use the standard.
      - WorldMaker 2y ago
        OData is still currently a standard for querying (among other things) nested data shapes. The point was it is a matter of fact that as a standard it predates GraphQL and as a matter of ecosystem perspective whether or not you think it is a more or less used protocol. To trade anecdotes for anecdotes: On Nuget, the Microsoft.Data.OData package marked deprecated and marked with CVEs for critical bugs still has an average of 36.3K per day downloads. (Its successors combine for about double that.) The top GraphQL library (of the same name, unadorned) still only has 9.3K per day downloads. In .NET if you want a system of querying nested data (that is also "REST compatible"), why would you use a less used protocol like GraphQL?
karmakaze 2y ago
One place I was at we used REST with a hydration service that ran as a proxy in front of the requests. That gave us most of the benefits of GraphQL and we only implemented it for the main resources (users, photos, and maybe one other thing). To minimize latency/faults the hydration service ran locally on every webapp/API server. I wasn't around for far too long after though to see how it turned out as it grew (if it did at all, the company sort-of went defunct--development-wise anyway). I also recall, we had similar N+1 query problems in the REST API endpoints irrespective of hydrating the returned resources. The biggest benefit of GraphQL I can see from a user perspective is that it lowers total latency especially on mobile with fewer round trips.
- bernawil 2y ago
  you don't think it's a benefit that you could get the benefits of a "hydration service that ran as a proxy in front of the requests" out of the box? there's lots of other benefits for GQL: multiple queries per request, mutation/query separation, typed errors, subscriptions support.
  - karmakaze 2y ago
    I currently use GraphQL and have no problems with it specifically, I was merely sharing an experience using REST. Perhaps it adds a bit of latency/overhead due to the implementation/language that's used but with larger requests rounds downward.
realusername 2y ago
> With internal REST for companies I have seen so many single page specific endpoints. Gross. Single page endpoints is exactly what you want if you have more than 5 engineers in your company anyways. It ensures that the endpoints are maintainable and future-proof when people are working on different features.
- hansonkd 2y ago
  > It ensures that the endpoints are maintainable and future-proof when people are working on different features How does GQL prohibit this? It encourages it by focusing on 1 stable API for everyone instead of a custom API endpoint for each case.
  - randomdata 2y ago
    It doesn't. That's literally what GraphQL was designed for: To provide a resolver that sits between high latency clients and all of the various REST/RPC services in order to roll up all of the requests at datacenter speeds into one in order to overcome the latency issues. But you still need all of the various single page REST/RPC endpoints to make use of GraphQL as it is intended. Some developers out there skip the REST/RPC part, making GraphQL their entire service, violating its principles. If it works it works, but it does not come tradeoff free.
    - hansonkd 2y ago
      ? why do you need a REST endpoint with GraphQL? Nearly every language has a GraphQL engine that integrated directly with the database and exposed functions as GQL directly without REST at all.
      - randomdata 2y ago
        You don't, obviously – we already talked about how many don't. But if you don't have a graph of "microservices" in which to query, what do you need GraphQL for? Especially if all you are doing is returning the results from a database. The database will already have its own API. Why not just use it? The native API is always going be better than your attempt to translate.
mattbrewsbytes 2y ago
If an app's API requires more than a couple of nested structures then, without knowing the specifics of the domain, I would venture a guess at a poorly defined data model is the issue vs. API technology. For example, a lot of times people build out nice normalized table structures for online transactional apps. The UI/UX is pretty straight forward because end users typically only CRUD an object maybe a couple nested objects at a time. The API's are straight forward as well, likely following single responsibility principles, etc. Then comes along requirements to build UI's for analytics and/or reporting types of things where nearly the entire schema is needed depending on what the end user wants to do. Its the wrong data model for doing those types of things. What should be done is ETL the data from the OLTP schema into a data warehouse style schema where data is de-normalized so that you can build reporting, etc.
billisonline 2y ago
> Ever seen an engineer do a loop and make n+1 REST calls for resources? It happens more often then you think because they don't want to have to create a backend ticket to add related resources to a call. > With internal REST for companies I have seen so many single page specific endpoints. Gross. As someone pointed out in reply to another comment, GraphQL is "a technological solution to an organizational problem." If that problem manifests as abuse of REST endpoints, you can disguise it with GraphQL, until one day you find out your API calls are slow for more obscure, harder to debug reasons.
WorldMaker 2y ago
> Ever seen an engineer do a loop and make n+1 REST calls for resources? It happens more often then you think because they don't want to have to create a backend ticket to add related resources to a call. With REST, though, that pain is visible to both sides. Frontend engineers generally don't want to make N+1 REST calls in a tight loop; it's a performance problem that they see and that is very visible in their Dev Tools. Backend engineers with good telemetry may not know why they get the bursts of N+1 calls that they see without asking the Frontend or digging into Frontend code, but they can still see the burstiness of the calls and have some idea that something could be optimized, that something is maybe too chatty. There are multiple ways with REST to handle things: pagination, "transclusions", hyperlinks, and more. Certainly "single page endpoints" is a way as well, no matter how gross it is from REST theory, it's still a pragmatic solution for many in practice. REST certainly can please everyone, given pragmatic compromises, even if it isn't very clear or standard.
mvdtnz 2y ago
> With internal REST for companies I have seen so many single page specific endpoints. Gross That's an established pattern (backend for frontend). Like all patterns there are trade-offs and considerations to make, but it's certainly not a priori "gross". https://learn.microsoft.com/en-us/azure/architecture/patterns/backends-for-frontends https://learn.microsoft.com/en-us/azure/architecture/pattern...
hi-v-rocknroll 2y ago
Perhaps that's the case for server-side transactions and ORMs over REST and gRPC to coordinate rather than allowing the front-end to diddle with data however it likes. And, resources with an index option obviously should have a db index or unique index. The challenges with GraphQL are that it makes it too easy to DoS services, leak internal data, break referential integrity, and there were a great deal of tools, infrastructure, and monitoring systems already available for REST (and gRPC to a degree). Company standards for REST and coding style can and should be set in the diff review pipeline. Another facet is setting standards to minimize duplication of effort or exposing a greater attack surface.

ComputerGuru 2y ago

> With internal REST for companies I have seen so many single page specific endpoints. Gross. Hardly gross. It is what it is and it’s universal across the domain. I bet Windows has internal APIs or even external ones that were created just for one page/widget/dialog of one app. It’s the nature of things at times.

hansonkd 2y ago
Its gross because it is a waste. An engineer had to spend time to make that specific API for that page instead of the frontend consumer using what was already defined and get all the resources with one call and 0 backend engineer needed for that new page.
- clintonb11 2y ago
  Is the flexibility worth the tradeoffs? Maybe in a company where you are adding new pages all the time with deeply nested relational data needs. But I would argue this is more rare than not. And I often find that frontend engineers aren’t as familiar with database queries and the load they are putting on the system with some of the graphql queries they are making. Flexibility for frontend has its own tradeoffs and I totally understand why a frontend engineer doesn’t want to have to wait for an endpoint to be finished. But this article outlines some of the issues you encounter later as you scale your team and system. We use a schema first design where I am at and if a frontend person needs a new endpoint because the resource-only endpoints aren’t enough then they submit a pull request to the schema repo with a design for their endpoint they need. It gets approved and boilerplate is auto generated. Yes you have to wait longer, but 90% of the time (for our software) the resource endpoints work great.
  - hansonkd 2y ago
    Sorry what are the tradeoffs? I'm not sure where this narrative comes from that GraphQL immediately means that the frontend time will have no idea what they are doing and will induce load on the system. 95% of my nested graphql fields are based on foreign key indexes so its almost no additional load to the system (only 1 query per "level" of GraphQL) to query the nested objects. I restrict GraphQL to 5 levels and now I have 5 queries per API call instead of 5 Queries over 5 API calls. The backend team exposes the fields that they know are efficient to query. They can restrict the depth of the GraphQL, number of fields, etc.
- pavel_lishin 2y ago
  On the other hand, it may take that engineer less time to create a page-specific endpoint than it would be to create something more generic that might serve other purposes (that may never come to pass), which may also involve talking to other teams, checking what future plans are, etc. And that's assuming it's a new endpoint; if there's an existing endpoint that does almost what's necessary, they may need to check in with that team about what modifications to the endpoint would be acceptable, etc. Single-page endpoints aren't great, but often times they're acceptable because they end up being a half-day task instead of a week-long slog.
datavirtue 2y ago
It's analogous to a specific method in code. No idea why people go nuts over this.
- hansonkd 2y ago
  A REST endpoint can be analogous to a specific method in code. just as much as a GraphQL field. What people are excited about is that the frontend can request all the data it needs at once and the backend can efficiently serve it. Something not possible with REST without reimplementing something similar to GraphQL.
  - RussianCow 2y ago
    It's definitely possible, just not without tight coordination between frontend and backend. When your development teams are broken into silos with strong separation, this isn't feasible and GraphQL starts to make some sense. Otherwise, you just create an ad hoc endpoint that serves the exact data you need and call it a day.
- arp242 2y ago
  Some people treat codebases as an art project rather than engineering project. I think this explains about three quarters of all engineering problems I've seen in corporate context, give or take.
- svieira 2y ago
  I suspect that people don't think about it too hard and presume that they should have only one model - that is that their REST model should map directly to their DB model which should map directly to their internal domain model (the idea that there might be two-or-more-domains and not-all-of-them-are-public hasn't even yet crossed their minds). When you realize that sometimes your REST model may be a view-model that maps to a different storage model optimized for online-transaction-processing, neither of which map to your internal domain model directly (there are adapters for that) _then_ you get somewhere ... but of course you then have to fight off the `transformToRestModel(transformToDomainModel(retrieveDbModel(theId)))` when the three models happily coincide for a time.

kiney 2y ago

Unpopular opinion: I'm actually a fan of singe page specific endpoints. You get much easier debugging, easier to audit security, easier performance optimization an the imho pretty small price to pay is that it's "not elegant" and a bit of backend code

shados 2y ago
The backend for frontend pattern. Something most apps where frontend and backend are in the same organization (fullstack or otherwise) should have. It does wonder to maintainability and performance. Even though we use GQL here, we still have a B4F, so it's browser -> B4F -> GQL -> Database. The tooling we use make it trivial so it doesn't add any development overhead (often reduces it. No CORS bullshit for one), and our app goes ZOOOOOOM.
nurple 2y ago
I think it's elegant. I loved MVVM in the postback world, and with SPAs, I see view-specific endpoints as the view-model continuing to reside on the server while the view was split off to the client-side.
datavirtue 2y ago
Agreed. Specific endpoints. I was on a project recently where a 40+ yr old dev was going crazy over "pure REST." It's embarrassing. Sure, have your pure REST but FFS create specific endpoints if you they make sense.
- mgkimsal 2y ago
  You are literally Transferring the REpresented State of a given page/view/screen. Screen-specific REST endpoints will make their way as a default in to a JS-based framework in 2025 and people will pretend like this is some breakthrough advancement.
  - mjburgess 2y ago
    And finally HyperText will progress into the futuristic HyperCard

theptip 2y ago

The canonical REST solution of query params to add nested fields gets you quite far: GET /myresource?extra=foo,bar sure you over fetch a bit if you have multiple accessors. But agreed, if you have highly nested data especially when accessed with multiple different query purposes then REST might not be the best fit. I think GraphQL has been positioned as a general purpose tool and for that I am with the author, REST is a better go-to for most usecases.

hansonkd 2y ago
I guess depending on the context of a simple app one level could be viewed as far. Any more levels and you have now reinvented GraphQL
- WorldMaker 2y ago
  OData existed before GraphQL in the wild, it's possible to suggest GraphQL reinvented OData. https://www.odata.org/ https://www.odata.org/
  - hansonkd 2y ago
    The point is GQL is currently the standard for querying dynamic nested data shapes not that it is the first or was the first. Look at OData download stats on Pypi it had 2 downlaods the last day. Graphql-core for python? 624,201. that is not even on the same planet. If you don't use GQL and want a system of querying nested data you will be using a less used protocol that is analogous to GQL so you might as well use the standard.
    - WorldMaker 2y ago
      OData is still currently a standard for querying (among other things) nested data shapes. The point was it is a matter of fact that as a standard it predates GraphQL and as a matter of ecosystem perspective whether or not you think it is a more or less used protocol. To trade anecdotes for anecdotes: On Nuget, the Microsoft.Data.OData package marked deprecated and marked with CVEs for critical bugs still has an average of 36.3K per day downloads. (Its successors combine for about double that.) The top GraphQL library (of the same name, unadorned) still only has 9.3K per day downloads. In .NET if you want a system of querying nested data (that is also "REST compatible"), why would you use a less used protocol like GraphQL?

karmakaze 2y ago

One place I was at we used REST with a hydration service that ran as a proxy in front of the requests. That gave us most of the benefits of GraphQL and we only implemented it for the main resources (users, photos, and maybe one other thing). To minimize latency/faults the hydration service ran locally on every webapp/API server. I wasn't around for far too long after though to see how it turned out as it grew (if it did at all, the company sort-of went defunct--development-wise anyway). I also recall, we had similar N+1 query problems in the REST API endpoints irrespective of hydrating the returned resources. The biggest benefit of GraphQL I can see from a user perspective is that it lowers total latency especially on mobile with fewer round trips.

bernawil 2y ago
you don't think it's a benefit that you could get the benefits of a "hydration service that ran as a proxy in front of the requests" out of the box? there's lots of other benefits for GQL: multiple queries per request, mutation/query separation, typed errors, subscriptions support.
- karmakaze 2y ago
  I currently use GraphQL and have no problems with it specifically, I was merely sharing an experience using REST. Perhaps it adds a bit of latency/overhead due to the implementation/language that's used but with larger requests rounds downward.

realusername 2y ago

> With internal REST for companies I have seen so many single page specific endpoints. Gross. Single page endpoints is exactly what you want if you have more than 5 engineers in your company anyways. It ensures that the endpoints are maintainable and future-proof when people are working on different features.

hansonkd 2y ago
> It ensures that the endpoints are maintainable and future-proof when people are working on different features How does GQL prohibit this? It encourages it by focusing on 1 stable API for everyone instead of a custom API endpoint for each case.
- randomdata 2y ago
  It doesn't. That's literally what GraphQL was designed for: To provide a resolver that sits between high latency clients and all of the various REST/RPC services in order to roll up all of the requests at datacenter speeds into one in order to overcome the latency issues. But you still need all of the various single page REST/RPC endpoints to make use of GraphQL as it is intended. Some developers out there skip the REST/RPC part, making GraphQL their entire service, violating its principles. If it works it works, but it does not come tradeoff free.
  - hansonkd 2y ago
    ? why do you need a REST endpoint with GraphQL? Nearly every language has a GraphQL engine that integrated directly with the database and exposed functions as GQL directly without REST at all.
    - randomdata 2y ago
      You don't, obviously – we already talked about how many don't. But if you don't have a graph of "microservices" in which to query, what do you need GraphQL for? Especially if all you are doing is returning the results from a database. The database will already have its own API. Why not just use it? The native API is always going be better than your attempt to translate.

mattbrewsbytes 2y ago

If an app's API requires more than a couple of nested structures then, without knowing the specifics of the domain, I would venture a guess at a poorly defined data model is the issue vs. API technology. For example, a lot of times people build out nice normalized table structures for online transactional apps. The UI/UX is pretty straight forward because end users typically only CRUD an object maybe a couple nested objects at a time. The API's are straight forward as well, likely following single responsibility principles, etc. Then comes along requirements to build UI's for analytics and/or reporting types of things where nearly the entire schema is needed depending on what the end user wants to do. Its the wrong data model for doing those types of things. What should be done is ETL the data from the OLTP schema into a data warehouse style schema where data is de-normalized so that you can build reporting, etc.

billisonline 2y ago

> Ever seen an engineer do a loop and make n+1 REST calls for resources? It happens more often then you think because they don't want to have to create a backend ticket to add related resources to a call. > With internal REST for companies I have seen so many single page specific endpoints. Gross. As someone pointed out in reply to another comment, GraphQL is "a technological solution to an organizational problem." If that problem manifests as abuse of REST endpoints, you can disguise it with GraphQL, until one day you find out your API calls are slow for more obscure, harder to debug reasons.

WorldMaker 2y ago

> Ever seen an engineer do a loop and make n+1 REST calls for resources? It happens more often then you think because they don't want to have to create a backend ticket to add related resources to a call. With REST, though, that pain is visible to both sides. Frontend engineers generally don't want to make N+1 REST calls in a tight loop; it's a performance problem that they see and that is very visible in their Dev Tools. Backend engineers with good telemetry may not know why they get the bursts of N+1 calls that they see without asking the Frontend or digging into Frontend code, but they can still see the burstiness of the calls and have some idea that something could be optimized, that something is maybe too chatty. There are multiple ways with REST to handle things: pagination, "transclusions", hyperlinks, and more. Certainly "single page endpoints" is a way as well, no matter how gross it is from REST theory, it's still a pragmatic solution for many in practice. REST certainly can please everyone, given pragmatic compromises, even if it isn't very clear or standard.

mvdtnz 2y ago

> With internal REST for companies I have seen so many single page specific endpoints. Gross That's an established pattern (backend for frontend). Like all patterns there are trade-offs and considerations to make, but it's certainly not a priori "gross". https://learn.microsoft.com/en-us/azure/architecture/patterns/backends-for-frontends https://learn.microsoft.com/en-us/azure/architecture/pattern...

hi-v-rocknroll 2y ago

Perhaps that's the case for server-side transactions and ORMs over REST and gRPC to coordinate rather than allowing the front-end to diddle with data however it likes. And, resources with an index option obviously should have a db index or unique index. The challenges with GraphQL are that it makes it too easy to DoS services, leak internal data, break referential integrity, and there were a great deal of tools, infrastructure, and monitoring systems already available for REST (and gRPC to a degree). Company standards for REST and coding style can and should be set in the diff review pipeline. Another facet is setting standards to minimize duplication of effort or exposing a greater attack surface.