|
 Hi, my name is Les, and this is my plan. Looking for my usual blog? Try 0xDECAFBAD. |
||||||||||||||||||||||||||||||||||||||||||||||||||||
|
I wonder if I'd like an eMate for writing in the sun? Jeff Barr on my recent blogging here: "Given the weird way that your paragraphs come through in your feed, I would think that OPML stands for One Paragraph Markup Language (if I didn't know better)." Yeah, this OPML blog can certainly do more than one paragraph per post. Lately, I've been trying to capture a thought or so per tiny paragraph post. But, this recent web services ramble I went on was more like a multi-point stream begging to be wrapped up in a single essay post. I ran out of steam, though, so I'll probably be back to tiny posts here soon. :) Someday, I'll probably finish that ramble on web services. Today is not that day. The general point I'd eventually get to is this: REST offers a way to architect web services using constraints into which most CRUD and content management APIs fit. The benefit of fitting into those constraints is that you get to take advantage of the thought and abstractions built up by lots of other people poking at those same constraints. The bespoke parts of your particular API shrink and the number of reusable bits from others grow. REST API design can become more of a research task for already-solved problems, rather than a creative exercise. The alternatives are using a mostly bespoke POX-style API or maybe a totally abstracted XML-RPC API. That was the thing that really got me started: Looking over the Facebook API and others, I see that we haven't really come that far from the original LiveJournal Flat protocol back in 2000 or so. Every web service has ended up being its own little snowflake, needing its own special treatment. The thing is, it's better than nothing so we trudge along and build the client libraries anyway. |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
