4 ms·

You're combining two issues. HTTP Digest requires the initial 401 unauthorized, but the same number of requests after that (And curl/libcurl handle it all for y

You're combining two issues. HTTP Digest requires the initial 401 unauthorized, but the same number of requests after that (And curl/libcurl handle it all for you, you don't need to think about it). I was just attempting to show what was going on, and why it was more secure than an API token. You're example requires that every API call use SSL, which means noone is allowed to cache it, which is going to be a hinderance on the scalability of you API (not impossible, though, but you're going to have to come up with your own, rather that just throwing squid in the middle). The other part is discovering of the service locations. By not doing so, you're handcuffing yourself. In your API, you are stuck forever with `/new.aspx`. Should you decide someday to have something else you want clients to be able to create, you can't separate it out into `/new_foo.aspx` and `/new_bar.aspx`. Doing these kinds of things actually make it less complicated in the long run, just like using jquery is less complicated than copy/pasting 50 lines of javascript of the web.

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 ago
  I 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.

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 ago
I 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.