Amazon Documentation :frowning:



  • I quote:

    The details in the notification describe the payment information and the sender information for the transaction. The tables in the following sections show the values included in the payment information, which vary depending on the exact nature of the transaction.

    The following IPN response elements are returned for standard and donation transactions, and for any other transaction that generates IPNs and is not specifically covered here.

    h1. Common IPN Response Elements

    These IPN response elements are common to most types of transactions.

    Fuckers.



  • In this case, probably Instant Payment Notification: "Instant Payment Notification (IPN) is a message service that automatically notifies merchants of events related to PayPal transactions. Merchants can use it to automate back-office and administrative functions, like fulfilling orders and providing customers with order status."

    TRWTF is notifying you in essense that the common response elements are defined as: common response elements. That's most of the time. Of course! So helpful!! (Just like this FRIST reply, in essence!)



  • Yup. That's the IPN I mean.

    This API is so inconsistent. I've been making Haskell types for all of the fields. And consolidating them when it makes sense. Except that, for example, addresses are passed around with the addressee's name in some cases. And without it in others. This is a big pain in the ass, especially considering that the common IPN elements have 20 optional fields, and the other kinds of elements have incompatible fields representing the same data. Fuckers.

    It's almost as though they didn't design this system, so much as do test driven development until it worked. I get the feeling that Amazon doesn't know how it works.

    It's no wonder I've been procrastinating all afternoon.



  • This post is deleted!

  • Discourse touched me in a no-no place

    @Captain said:

    This API is so inconsistent.

    Welcome to the web. It gets worse from here on in.

    Academic web services have awful APIs by and large: pass a mysterious string that isn't explained anywhere in — but which is fed without de-escaping to a complex rules engine — and get a different mysterious string out. That might be XML except they used the wrong sort of templating. The exemplar javascript code uses regexps to parse it, and those are wrong.



  • The best API I ever worked with was when I was porting a Java applet to being in JavaScript, and used this funky XML format for interchange, except the original author had kind of missed the entire point of XML. Like returning a body with <Flag> items, like <Flag>1</Flag> and the documentation said, and I quote, 'whether a flag is returned'.

    This was combined with some exciting state behaviour where the app would return several panes of information and the client had to request which pane it was dealing with when it came to doing anything, only half the time it had to infer what the pane's id was based on what the server had sent before because the server didn't necessarily send the pane id correctly.

    Mind you, this was some bat shit insane stuff like web request -> Java -> C# -> database with a bunch of proprietary libraries in the middle. I ended up figuring out the logic by decompiling the Java applet (which had all the debug information in it, even in a production environment!) and was entirely in favour of an end to end rewrite to leave a sane API and stuff, especially because the company was in favour of having different UIs for different datasets, which would have been cool if the retardedness of the API could have made it possible.



  • Disappointment. What I get for assuming competence.

    I ended up moving to a different payment system. It's the same price. The API is sane. And there's a library for Haskell. I've just about finished the wrapper for it.



  • So, you're the RWTF for assuming competence from a big company? 😛



  • Yeah, kind of. My first job was a TDD Perl shop. And while it was definitely a supportive environment with not very many WTFs, it had the standard Agile WTFs. Including the lack of design or quality combinators, especially in my group.

    I switched to Haskell to avoid that particular brand of WTF, which I find particularly frustrating. (Also, it plays to my strengths -- I have a BA in math)


  • Discourse touched me in a no-no place

    @Arantor said:

    This was combined with some exciting state behaviour where the app would return several panes of information and the client had to request which pane it was dealing with when it came to doing anything, only half the time it had to infer what the pane's id was based on what the server had sent before because the server didn't necessarily send the pane id correctly.

    Sounds normal. Did the item order stay the same between requests? Once had to deal with an API that implemented paging, but fucked that up causing a random selection of items from the first page to appear on the second. The implementors didn't notice for years because not many lists actually needed paging…



  • That's just it, the server would send a pane of data and invariably the next request would produce a new sub-pane. Occasionally it would trigger a rebuild of that pane, with the state synchronised across the session and nothing in the spec would ever tell the client for sure what was correct - only an ambiguous and unhelpful error if you got something wrong.

    What little API spec there was turned out to be incomplete in some places and completely wrong in others, to the point where I was analysing stuff with a packet sniffer to figure out what the hell was going on, which sucked on too many levels.


Log in to reply