I don't mean to be an ungrateful punk, but Jyte's API really sucks right now. Here are a few things I think would help:
- Instead of combining method names into the URL, provide a single API endpoint that accepts a method parameter.
Bad:
http://jyte.com/api/group/Rubyists/is_member?openid=wonko.com
Good:
http://jyte.com/api/?method=group.is_member&group_name=Rubyists&openid=wonko.com
- Return results in a consistent JSON, XML, or YAML format for ease of parsing. The current plaintext responses are easy enough to parse, but aren't consistent and don't contain any metadata, which means API consumers have to write method-specific parsing code.
- Don't use HTTP error codes for API errors! Currently, calling group/Rubyists/is_member and passing the name of a user who isn't a group member results in an HTTP 400 "Bad Request" error. This makes the consumer think the request failed, when really the request succeeded (it's also a bug, since the API docs say the call should return "false" in this case).
- Draw inspiration from the Flickr API, which is (imnsho) one of the best public REST APIs there is at the moment.
Discussion (11)
Not to be an ungrateful punk, but this is the sort of thing that would make a better support email than a claim.
Not to nitpick, but the FAQ seems to imply that you like feature requests to be claimed: http://jyte.com/help/#featurerequest
:P
It does help us prioritize feature requests.
Which? Claiming them or emailing them?
Claiming them, since people can vote on their favorites. Email is better for reasoned criticism, I think.
Got it. I'll use email in the future.
Great to see the Jyte API so far. Having the results returned in a more structured format would help us build more extensions.
Apparently, Ryan doesn't understand REST either.
Having an error status code represent an error is a REALLY good thing. Having some informative entity body on such an error is an even better thing. Then there's no way the user could suspect that the request itself failed.
Apparently nic is a dumbfuck and can't read.
Having an error status code is a good thing, but in the case I described in this claim, the REST request was valid and should have been considered a successful request with a negative response. Instead, I got an HTTP error informing me that the request had failed, when in fact it hadn't.
This is akin to a Java boolean method throwing an exception instead of returning false.
I agree with the title -- but not the body... I prefer pretty urls for some things (group membership)
yeah, I prefer the method to be the path. I agree with the comments regarding the status codes. The forthcoming pibb api will demonstrate what we've learned about APIs in the past year.