Gregory Szorc's blog

New Syndicated Feeds Available for the Case Wiki

I completely rewrote the syndicated feed generation for the Case Wiki today (for the 3rd time). Feeds are now available at Special:WikiFeeds. If you run MediaWiki, you too can enjoy the enhanced features of this plugin. Source code is available at My MediaWiki Project Site.

I'll be redirecting the existing feeds to route to this new script. If anybody notices any issues with the feeds not validating or any other strange behavior, please let me know by e-mailing wiki-admin@case.edu or leaving a comment on CaseWiki:ToDo.

You can ping this entry by using http://blog.case.edu/gps10/mt-tb.cgi/6737 .

There was some discussion in the comments of Greg's entry New Syndicated Feeds Available for the Case Wiki concerning what...

Trackbacked from How to Create a REST Protocol on Jeremy Smith's blog.

Good job. I'll have to look at the differences and update my share of Case Classes.

One thing though:

Feeds are requested using a RESTful interface. All requests take the form of Special:WikiFeeds/format/feed/param1/value1/param2/value2 etc

I've only encountered this parameter style once before, and it was an option in Zope. Otherwise I think it's not very popular for good reason: just because there aren't ?any=funny&looking=parameters doesn't make it REST proper. The /user/Gregory.Szorc and /category/Buildings, OK, maybe those are resources. But things like count=50 should be left in the proper uglified style.

The old URL's are serving out 301 Permanent redirects to the new feeds. As long as your client follows redirects, everything should be good.

I could get 10 people in a room and they would all have different opinions of how to implement REST. I see the logic in your comments and will consider changing the implementation. Part of the reason for the choice is not wanting to mess with the query string. ATOM insists that the feed id match the URL it was obtained from. Using the $_SERVER variable in PHP is bad form and MediaWiki makes it somewhat difficult to use query string parameters in URL's. All-in-all, it was easier to do it this way.

Would you approve of me leaving the current query format intact but removing the reference to REST?

I don't actually care, but what's the point of trying to adhere to all these pseudo-standards if you can't call people out on them? ;)

I want to adhere to standards too! Feel free to call me out whenever I inject false assertions into product descriptions. I hate when Oracle does it. I sure don't want to do it myself. Whatever our definitions of REST may be, we can still agree that http://30boxes.com/api/ is not REST ;) Jeremy likes to keep tabs on these things. I am surprised he hasn't chimed in yet. He is probably busy trying to find a special case where the feeds don't validate.

The design of a URI scheme is orthogonal to the principles of "REST." In REST, URIs (or more properly nowadays, IRIs) are just opaque strings. An opaque string that represents a resource that is dereferencable.

A URL like the following:

http://www.host4.example.com/awefj/index.sswf/path/to/places?queryarg1=something&foo=bar&baz=quuxwhuffie

That URL is no less "REST" than a URL that looks like:

http://example.com/products/microwave

It's about the behavior of the resources behind those URLs that make something "RESTful." It has nothing to do with what a URL looks like or how many letters are in it or how it represents its arguments.

With that out of the way. When you are designing a URL scheme, just do so sensibly. Make it "guessable." Make it search-engine goodness.

(I keep typing. I can't stop. It just... okay, I just deleted like 4.5 paragraphs of REST rambling about how URIs identify resources and that's the important part, not the format of the URL.)

All right, I am stopping now. I am stepping away from the keyboard.

In conclusion, there's nothing wrong with your URLs, Greg, except that they may cause people to ask you to change them.

...or how it represents its arguments.

If that were true, then what's wrong with: /api.php?method=user.FindById&id=47

For all you know, that *is* opaque, they could make that unique query do any number of things on the server side without changing the URI. It also represents a unique resource, dereferencable, etc.

If that were true, then what's wrong with: /api.php?method=user.FindById&id=47

Right, there's nothing inherently wrong with that URL.

I should have typed more.

The resource behind that URL "/api.php?method=user.FindById&id=47" might be behaving in a "non-REST-ful" manner. That is, it might just be executing function calls encoded in the URL. If that's the case, no harm, no foul. Just don't call it a "RESTful API." It's no more RESTful than it is SOAPful or XML-RPCful. It's URI-Encoded-RPCful.

God, I really need to stop appending stuff with "ful." Starting to make myself sick.

It's about the behavior of the resources behind those URLs that make something "RESTful."

So what does make something RESTful? Using POST instead of GET where appropriate?

Also, since RESTful URIs are supposed to be opaque, isn't it non-RESTful to expect clients to build up URIs from some kind of pattern, rather than having a collection of resources that link to each other using opaque identifiers?

Now I'm rambling on, but please allow me to continue...

What makes REST and "URI-encoded RPC" mutually exclusive, anyway? Suppose there is a system consisting of a collection of resources, connected by links. Each resource is identified by a URI. You can GET each resource to look at it, and you can POST things to some of the resources to change them. Is this not a RESTful system?

Now suppose the URIs are of the form /api.php?method=user.FindById&id=47. Also suppose the system really does just execute actions that are encoded in the URL. Since the URLs are supposed to be opaque, the encoding is just an implementation detail.

So does REST come down to not making your users manufacture URLs for resources, but instead providing links to them from other resrouces? What am I missing?

No, you've got it, Andrew. The URIs are opaque. A GET to /api.php?method=user.FindById&id=47 (even if it does happen to call a specific code function user.FindById with a parameter of 47) is not (damnit, I'm about to do it again) "non-RESTful."

To better illustrate, in this post, RPC in URIs is not REST:

It's not REST. If you find yourself typing something like the following in your API documentation... [y]ou know it's not REST.

The problem with their API is not directly tied to what URLs they are using. From their documentation:

The AddItem Request

This request adds an owner-item relationship. The parameters are:...

What they are doing is using a GET request to "add an owner-item relationship." That is, if you execute a GET to a URL like:

http://server1.easyutil.com/recommend.php?cid=123&operation=AddItem&owner=jms18&tag=foo&item=widget

You end up changing the state of the server... through a GET! Imagine a web crawler hitting tons of those different URLs making GET requests over GET requests constantly changing the state of the server over and over again. That is not RESTful.

Did that make it more clear? I'm worried that my ramblings are making things murky.

One of the rules of REST: GET should be idempotent.

sportsinteraction

retty much nothing seems worth thinking about. My life's been completely dull , not that it matters. I've just been staying at home waiting for something to happen.

movie clips masturbation female masturbation galleries

Jonathan Ross is dubbed "risque" by Ofcom but not in breach of rules over an interview with David Cameron...