HN user

al3xdm

17 karma
Posts0
Comments7
View on HN
No posts found.

Only for buyers. Sellers need to be U.S based.

To get started for free, sign up for an Amazon Payments seller account. You will need your legal business name, contact information, a US credit card, and a US address. After you sign up, you'll be able to use our tools to create HTML that you can copy and paste into your website code to show our button and start accepting payments.

https://payments.amazon.com/business/html-button

Birmingham, UK - Full time - Web Developer

We're a well funded Birmingham based startup looking for a talented developer to join our team. We're a team of three developers growing to six over the next couple of months.

Open to applications from a diverse range of backgrounds, whether you're an experienced dev with commercial experience, university graduate or not done/completed a degree. Just have a passion for development and a project or two to show us.

Key points

  - You'll have experience with PHP. We run Hiphop, make use of Unit Tests and create/path extensions as necessary.
  - You will be designing and working from several internal APIs, and experience with APIs (public or private) is good.
Whats in it for you?
  - Your an early hire - competitive salary and equity.
  - Equipment of your choice.
  - Nice offices based in the Custard Factory.
  - Flexible work hours and days.
  - Free drinks/snacks, cinema pass / gym membership.
If you're interested send me an email - alex [at] hobzy.com

Multi region failover is seriously inhibited with their current VPC setup as cross-region traffic is ridiculously complicated to get working.

We are on the "EC2 Original" setup with a Cassandra cluster operating over regions via Elastic IPs. We tried to setup a multi-region cluster on their "EC2 VPC" mode and gave up. A VPC can only span a region and currently no easy way to manage traffic between them. We looked at getting a VPN connection but the cost for a decent connection gets way prohibitive.

Hi Matthew,

You suggested that the FBI could re-write the API request to be: http://api.fbi.gov/wanted/most

Which would return a set of known fields. You then go on to say:

"After complaints that “notoriety” is a made-up number, the FBI can hide the field; the intent-driven design is unchanged."

This suggests that the API author is free to add, remove or rename fields in the response without bumping version as it's part of the "intent-driven design".

In response to your second point, I then don't understand what the real purpose of intent-driven API design is. The only different appears to be that you given more RESTful URLs than using loads of query parameters?

I'm not sure this works once other people start building on top of your API though. I would rather bump the API version than break API compatibility by adding/removing/renaming fields.

Github (which you used in your example of good design) do change fields returned in their API responses but only between API version not inside of versions. The link you gave [1] is to Version 3 of their API which is different to Version 2 and will be different to Version 4. I don't really want to be programming against APIs where identical requests can return varying responses based on supposed intent.

1. http://developer.github.com/v3/repos/statuses/