3 ms·
Hmm. You seem to have rebutted my argument by retyping your article. The API in question has exactly one endpoint, so no possible value could come from having
by jasonkester 17y ago
Hmm. You seem to have rebutted my argument by retyping your article.
The API in question has exactly one endpoint, so no possible value could come from having to look it up on a list each time you want it. And it is a POST to create something, which means you'd never cache it.
I picked that example because it is an existing use case that demonstrates that the rules you're proposing don't apply to every situation.
- psadauskas 17y agoI must have missed the part where you said the API would only have one endpoint, ever. Roy's thoughts on the constraint is that there is only one well-known entry point, and my article was a little more lenient with "very few". Each one, however, is an additional maintenance burden on both the app writer and a client writer. If your app only has a single resource, then there's no reason why it can't be the one well-known resource itself. There's no need to be snarky, these constraints apply perfectly to your application as it is. If you have any intentions of your app growing beyond that single resource, however, its not that complicated to add these constraints to make that future growth easier.