|The API Bunny Challenge||Steven Willmott||4/18/14 8:24 AM|
Happy holidays - we thought we’d have a little fun and put together this: http://apibunny.com - just launched. There’s a challenge there to solve and I’m betting someone from this group will be first.
Made with fortune.js and jsonapi :).
Super simple but hopefully will get a few folks to figure out an API!
|Re: The API Bunny Challenge||Nick Floyd||4/18/14 9:08 AM|
Loads of fun, I'm still running it - just a quick note you have a typo in one of your results: "Next to rover the the family dog"
Thanks for this! I love doing these types of things.
"name": "Next to rover the the family dog",
|Re: [api-craft] Re: The API Bunny Challenge||Steve Klabnik||4/18/14 9:32 AM|
This is great!
|Re: [api-craft] The API Bunny Challenge||Brian Mulloy||4/18/14 10:37 AM|
(there goes a bunch of free time)
|Re: [api-craft] Re: The API Bunny Challenge||Steven Willmott||4/18/14 10:06 AM|
Thanks Nick - will fix that!
|Re: [api-craft] The API Bunny Challenge||Ryan Hiebert||4/18/14 11:55 AM|
Blast! I need a hint on how to interpret that exit url. Doesn't look like there's anything in the JSON API spec about it, and I can't find an object format that works.
|Re: The API Bunny Challenge||Mehdi Medjaoui||4/18/14 6:58 PM|
I give up!
In attached file, I've put in pdf the paths I've been through...if it can help people... (collaborative browsing)
|Re: The API Bunny Challenge||MattM||4/19/14 9:32 AM|
Don't trust the API Bunny! It's a trap! ;-) m@
|Re: [api-craft] Re: The API Bunny Challenge||Steven Willmott||4/19/14 10:29 AM|
Lol - glad it was fun. Mehdi - I guess the post at the end was non intuitive. Were were going to use something with just links for get ( Mike Amundsen also pointed that out) but this was we could use fortune.js which made it super easy!
|Re: [api-craft] The API Bunny Challenge||Steven Willmott||4/19/14 10:30 AM|
|Re: [api-craft] The API Bunny Challenge||Mehdi Medjaoui||4/19/14 11:15 AM|
As feedback: Yes with my friend (@tiborvass on twitter ) we tried to explore/discover the maze it in an automated way (never making 1 human-made logic call)
It publishes also a pdf at the end of the path record he made( for humans this time)
So the POST at the end was impossible to understand for our crawler (mainly because we did not understand it ourselves too ;) )
Sent from my mobile : so typos are not mistakes but features.
|Re: [api-craft] The API Bunny Challenge||Mike Amundsen||4/19/14 11:40 AM|
was very interesting to watch people interact with this service.
esp. for machine-driven experience, you need to find a way to express *all* the protocol details (URI, method, arguments) inline in the response. HTML Forms. Cj templates, Siren actions, UBER data elements. these all express the full set of protocol details - no additional human-readable docs needed.
Atom, HAL, JSONAPI, Mason all rely on additional human-readable docs to explain how to actually change state (write data) on the server.
|Re: [api-craft] The API Bunny Challenge||Jørn Wildt||4/19/14 12:10 PM|
> Atom, HAL, JSONAPI, Mason all rely on additional human-readable docs to explain how to actually change state (write data) on the server.
Sorry, but I have to correct you here. Mason *does* indeed have actions. These are JSON based and depends on JSON schema and prefilled JSON templates to describe the payload. If you take a look at the issue tracker demo you will see that Mason describes each and every possible state transition needed to create, search, change, delete etc. and even upload files (which none of the other formats you mentioned handles btw). There is even a Mason browser to illustrate how a generic client could visualize and interact with the format.
|Re: [api-craft] The API Bunny Challenge||Mike Amundsen||4/19/14 1:16 PM|
thanks for stepping in to help me better understand Mason.
i've read through the docs a couple times and here is what i can determine:
link and link-template always use GET
actions always use POST unless the "method" argument appears and then that action uses the method supplied (PUT or DELETE).
is it legal to use GET for an action method value? PATCH?
|Re: [api-craft] The API Bunny Challenge||Steve Klabnik||4/19/14 2:02 PM|
This is also where profiles come in...
Sent from my iPhone
|Re: [api-craft] The API Bunny Challenge||Jørn Wildt||4/19/14 4:59 PM|
Mike, since you obviously have read and understood the spec what is it then that makes you say that Mason needs human readable documentation to describe how to change state? I fail to see what is missing - especially if you say Sirene doesn't need human readable specs (I would say that Mason is more expressive in this area).
Yes, actions defaults to POST unless you specify another method (similar to HTML forms which defaults to GET). There are no restrictions on the choice of method (unlike HTML forms).
Yes, GET is valid for an action of type "void" (meaning an action with no payload). Same goes for DELETE which has no payload - as well as empty POST or PUT operations.
You can furthermore have inline action descriptions targeted at the client developer to help understating the API when exploring it manually.
PATCH is in principle possible for an action of type "json" since JSON-patch is JSON, but that would be to stretch the semantics a bit. PATCH is in my opinion (these days) way too document oriented for the kind of business operations that Mason was designed for so it has been left out by purpose.
Neither is Mason prepared to handle other HTTP methods that requires something else than JSON in the payload (except for multi part used for file uploads) - just like HTML forms is restricted to either key/value forms or multi part forms.
|Re: [api-craft] The API Bunny Challenge||Mike Amundsen||4/19/14 5:53 PM|
I think I misunderstood the spec and it wasn't until I re-read it that I was able to see the the description of POST as default for actions. It was this failure on my part to understand the spec that led me to include Mason in the list of formats that rely on human-readable docs to understand protocol-level information.
I agree (based on my re-read) that Mason offers the oppty to describe protocol-level details.
I *apologize* for this mistake, ok?
|Re: [api-craft] The API Bunny Challenge||Jørn Wildt||4/19/14 6:53 PM|
Mike, thanks for trying to understand me :-)
|Re: [api-craft] The API Bunny Challenge||Mike Amundsen||4/19/14 6:55 PM|
thanks for offering up the design and for taking the time to help me learn how it works.
|Re: [api-craft] The API Bunny Challenge||Steven Willmott||4/19/14 7:52 PM|
Thanks for discussion here - yes, it turned out into an unexpected interesting experiment. I’ll take a look at the data and try to summarize it back for here.
The POST action definitely hit people and indeed there wasn’t a machine readable definition. We also did obfuscate that. A lot of people tried to navigate manually and a couple wrote scripts. I’m going to try to see if I can get a couple of them.
|Re: [api-craft] The API Bunny Challenge||Mike Amundsen||4/19/14 8:08 PM|
would be really cool if you could turn this into an open source project. post the server and then allow folks to post their clients.
we could all learn alot from this very cool project. thanks.
|Re: [api-craft] The API Bunny Challenge||Daniel Yokomizo||4/20/14 8:42 AM|
I wrote a quick and dirt bash client (https://github.com/dyokomizo/apibunny) to explore the maze, using wget and jq, but it missed the exit link too.
Also I never managed to correctly POST to the exit, I got 412s and 400s. Is there a hint on what kind of JSON it expects?
|Re: [api-craft] The API Bunny Challenge||Ryan Hiebert||4/20/14 11:30 AM|
> On Apr 20, 2014, at 10:42 AM, Daniel Yokomizo <daniel....@gmail.com> wrote:JSON-API JSON.
Sent from my iPhone
|Re: [api-craft] The API Bunny Challenge||Steven Willmott||4/20/14 12:49 PM|
Yes, this is a good idea, we’ll try to get that done as soon as we can & gather up links to the scripts that people had. Will post here when done!
|Re: [api-craft] The API Bunny Challenge||Mike Amundsen||4/20/14 1:29 PM|
|RE: [api-craft] The API Bunny Challenge||Markus Lanthaler||4/21/14 12:43 PM|
On Friday, April 18, 2014 5:24 PM, Steven Willmott wrote:
> Hi all,
> Happy holidays - we thought we’d have a little fun and put together this:
> http://apibunny.com - just launched. There’s a challenge there to solve and I’m
> betting someone from this group will be first.
This is great, thanks a lot Steve for creating this. I used this opportunity to test your APItools  and converted it to a JSON-LD + Hydra powered Web API . The result is accessible at:
Unfortunately APItools' JSON library doesn't allow pretty-printing (at least I haven't found it) so the responses look quite ugly if you use curl. You can use the Hydra console to access and navigate this API:
Hold down the shift key when you click on a link to avoid that modal to pop up.
Please note that submitting your twitter handle doesn't work as I was too lazy to convert the JSON-LD that the console sends to the API to JSONAPI but you see that it renders the form etc.
|RE: [api-craft] The API Bunny Challenge||Steven Willmott||4/21/14 1:05 PM|
Ho Ho - wow, this is super cool! I’ll check on the pretty printing,
Like the console a lot too.
|Re: [api-craft] The API Bunny Challenge||Evan Stoner||4/23/14 2:56 PM|
On Sunday, April 20, 2014 11:30:04 AM UTC-7, Ryan Hiebert wrote:
> On Apr 20, 2014, at 10:42 AM, Daniel Yokomizo <daniel....@gmail.com> wrote:
Any hint on what the keys should be? I think this is valid JSON API from eyeballing it, but it doesn't seem to work.
|Re: [api-craft] The API Bunny Challenge||Ryan Hiebert||4/23/14 3:02 PM|
It's been a minute since I figured it out, but I think that you don't need the list to contain objects, just strings. I hope my memory isn't failing me ;-)
|Re: The API Bunny Challenge||Nicolas Grenié||4/24/14 11:06 AM|
We just post a blog post to explain how we did create APIbunny and giving the last hint to do the POST request.
Hope it helps :)
Thank y'all for playing with it,
|Re: [api-craft] Re: The API Bunny Challenge||Ryan Hiebert||4/24/14 11:19 AM|
Ah, yes. My memory was failing ;-)