3 ms·

Design is hard. In the given example we work with an Article domain. Where there are Comments. Fine and totally fair. But how would you design your object gr

Design is hard. In the given example we work with an Article domain. Where there are Comments. Fine and totally fair. But how would you design your object graph from the bottom up? Articles and Comments is a fairly simple example. Imagine a Transaction in bank domain context. Would you have an endpoint like so? transactions/:id/acoount/:id Or perhaps transactions/:id account/:id/transactions Whatever you pick you must find a way for transactions and accounts to work together on a design level, which will impact how you potentially serve services and how you deploy them. Is an account and a transaction part of the same domain and service? It's hard to design proper REST apis because although it's easy to dish out cool looking routes, it might be a lot harder to actually design your systems based on those routes.

JimDabell 6y ago
REST doesn’t really have the concept of endpoints. That’s a hierarchy some people artificially impose over the top of a REST system. REST doesn’t require it. All of your URLs could be randomised and a REST system would work exactly the same. You don’t need hierarchy in your URLs. If you want to load a transaction, then /transactions/123 is fine. If you want to load an account, then /accounts/456 is fine. You don’t need to put one under the other. In a REST API, the primary key for a resource is the URL. If you have the primary key, URL hierarchy is unnecessary. Just use whatever is clearest for a developer to identify at a glance for debugging purposes. It’s not required by the tech.
- NanoWar 6y ago
  This is true and I use top level URLs for all of my resources in a REST api. You can however to a POST to articles/:id/comments and return location headers pointing to /comments/:id easily!
mewpmewp2 6y ago
It would be for all transactions /transactions and for transactions for a particular account /accounts/:id/transactions.
tsimionescu 6y ago
Sure, but this is unavoidable complexity for any API designer, whether it's REST or C or SQL. Of course you need to think about how to model the business domain and what entities you will expose, and the relations between them.

JimDabell 6y ago

REST doesn’t really have the concept of endpoints. That’s a hierarchy some people artificially impose over the top of a REST system. REST doesn’t require it. All of your URLs could be randomised and a REST system would work exactly the same. You don’t need hierarchy in your URLs. If you want to load a transaction, then /transactions/123 is fine. If you want to load an account, then /accounts/456 is fine. You don’t need to put one under the other. In a REST API, the primary key for a resource is the URL. If you have the primary key, URL hierarchy is unnecessary. Just use whatever is clearest for a developer to identify at a glance for debugging purposes. It’s not required by the tech.

NanoWar 6y ago
This is true and I use top level URLs for all of my resources in a REST api. You can however to a POST to articles/:id/comments and return location headers pointing to /comments/:id easily!

mewpmewp2 6y ago

It would be for all transactions /transactions and for transactions for a particular account /accounts/:id/transactions.

tsimionescu 6y ago

Sure, but this is unavoidable complexity for any API designer, whether it's REST or C or SQL. Of course you need to think about how to model the business domain and what entities you will expose, and the relations between them.