Some usability feedback: It seems like the most useful information is contained in the links between nodes, but at first it was not obvious to me that they were clickable, or that clicking the text links at the bottom of node descriptions would actually show the 'link' description, rather than just taking me to the next node.
I'd recommend you make it clearer that the linking lines between nodes are clickable. Even better, rather than using a modal dialogue to display node contents, you could use a popover with an arrow pointing to it's owner. Clicking a link a the bottom of an item would simply move the popover, making the relationships between various items of content clearer.
Thanks for the feedback. There are usability issues, and as you point out, the importance of the links is not evident at a first glance. I like the popover idea; I'll have to give that a try.
I like the idea. Have you considered adding weights? I'd also consider linking to a more detailed source (wikipedia?) when available.
On the topic of idempotence..we recently made our platform distributed across 4 datacenters using queues. None of us really knew what we were doing. Recognizing this very early on, we made all calls idempotent. Pretty sure that single decision is what made the entire system work.
I have absolutely considered adding weights. But, it quickly leads to the idea that my priorities are not necessarily the same as everyone else's, and that leads to user-customizing, and that leads to... well, it got to some cool ideas, but I figured first I should shove this out the door in a simple form and see if people like the concept. If the concept is well-received, I'll continue to develop it and explore other API best practices in a similar manner.
The enterprise integration patterns links are interesting to me; thanks for point those out. I can definitely see how they could use a connection to reality. I can look at a random one and see what it is, but understanding why you'd use it is a mile above my head.
Idempotence (literally "same power) in a REST API means a given request produces the same result whether you execute it once or multiple times. Given the URL:
/resource/1
Whether you execute the DELETE method on that resource once or ten times, the resource is deleted. Therefore, it is idempotent.
This is something I've wondered about. So you get a DELETE request against /resource/1 and you delete the resource. When you get the second DELETE request, shouldn't that give a 404, since the resource no longer exists?
Ah I see. So idempotency is determined by the resulting state (ie. the state of the manipulated resource at the end of the interaction), not the action taken (server removes the resource on the first DELETE, but not on the second). Thanks Ryan!
Very interesting, but I would say your tradeoffs aren't really accurate. Idempotency should decrease testing and maintenance costs because it is simpler.
I don't get why there should be an intrinsic higher development cost since you're building a simpler, saner and better-defined system. If anything, it would decrease development costs.
It will decrease development costs for the end users, but most times when you say you want a simple api, you mean you want to take a really complicated system and wrap it up in a far simpler interface (hence the "abstract" part).
Making good abstractions for a complicated system is always harder than just a 1:1 API.
If you think technical prowess is a requirement for being a boss, reality is going to be quite shocking for you.
And, I don't even think it should be a requirement (depending on the role), if said boss hired you because you have the technical experience needed and trusts you, and is willing to learn, I wouldn't mind working for him.
Because a good boss makes sure you've actually thought about what you're doing, not just blindly parroting "design patterns", "best practices" and "standards".
Don't get me wrong, all of those are generally good things, but if you can't draw up a diagram like that in 30 minutes for any design pattern, best practice or standard you follow, you should take that as a hint that you're doing something wrong.
The term is very well-established in mathematics (for e.g. matrices and transformations) that is the precisely correct term for this, and it is already widely used in CS. Inventing a new word would not be helpful in the long run.
What do you mean by 'nicer' word? I really honestly don't get it.
I mean if it were some consumer property, like say the size of a hard drive or such, then yeah makes some sense, for a term used in strictly in technical circles to describe a precise technical property, I don't understand what 'nicer' means.
[+] [-] mambodog|13 years ago|reply
I'd recommend you make it clearer that the linking lines between nodes are clickable. Even better, rather than using a modal dialogue to display node contents, you could use a popover with an arrow pointing to it's owner. Clicking a link a the bottom of an item would simply move the popover, making the relationships between various items of content clearer.
[+] [-] mfenniak|13 years ago|reply
[+] [-] latch|13 years ago|reply
On the topic of idempotence..we recently made our platform distributed across 4 datacenters using queues. None of us really knew what we were doing. Recognizing this very early on, we made all calls idempotent. Pretty sure that single decision is what made the entire system work.
[+] [-] mfenniak|13 years ago|reply
[+] [-] j-m-o|13 years ago|reply
I know they don't get too much love on HN, but it would be cool to see this done for a set of enterprise integration patterns.
See:
http://www.eaipatterns.com/toc.html
http://camel.apache.org/enterprise-integration-patterns.html
[+] [-] mfenniak|13 years ago|reply
The enterprise integration patterns links are interesting to me; thanks for point those out. I can definitely see how they could use a connection to reality. I can look at a random one and see what it is, but understanding why you'd use it is a mile above my head.
[+] [-] RyanMcGreal|13 years ago|reply
Idempotence (literally "same power) in a REST API means a given request produces the same result whether you execute it once or multiple times. Given the URL:
/resource/1
Whether you execute the DELETE method on that resource once or ten times, the resource is deleted. Therefore, it is idempotent.
[+] [-] jmcqk6|13 years ago|reply
[+] [-] mattacular|13 years ago|reply
[+] [-] jamesaguilar|13 years ago|reply
[+] [-] amiheines|13 years ago|reply
[+] [-] hcarvalhoalves|13 years ago|reply
[+] [-] akiselev|13 years ago|reply
Making good abstractions for a complicated system is always harder than just a 1:1 API.
[+] [-] mattacular|13 years ago|reply
Ex. "Request = DELETE ID 1"
First request, ID 1 is deleted. Second request, ID 1 has already been deleted. Third request, ID 1 has already been deleted.
[+] [-] ExpiredLink|13 years ago|reply
http://www.infoq.com/news/2013/04/idempotent
[+] [-] nahname|13 years ago|reply
[+] [-] GFischer|13 years ago|reply
And, I don't even think it should be a requirement (depending on the role), if said boss hired you because you have the technical experience needed and trusts you, and is willing to learn, I wouldn't mind working for him.
http://management.fortune.cnn.com/2011/06/01/why-bosses-dont...
[+] [-] mseebach|13 years ago|reply
Don't get me wrong, all of those are generally good things, but if you can't draw up a diagram like that in 30 minutes for any design pattern, best practice or standard you follow, you should take that as a hint that you're doing something wrong.
[+] [-] dscrd|13 years ago|reply
[+] [-] daviddaviddavid|13 years ago|reply
I've variously heard people say both i-dem-PO-tent and i-DEM-po-tent. (In the latter, the "o" in "po" gets reduced to a schwa.)
[+] [-] msg|13 years ago|reply
Fixed point is another way to get at it, although it requires your listener to know what that is.
[+] [-] bmm6o|13 years ago|reply
[+] [-] apalmer|13 years ago|reply
I mean if it were some consumer property, like say the size of a hard drive or such, then yeah makes some sense, for a term used in strictly in technical circles to describe a precise technical property, I don't understand what 'nicer' means.
[+] [-] losethos|13 years ago|reply
[deleted]