<?xml version="1.0" encoding="UTF-8"?>
 <rdf:RDF xmlns="http://purl.org/rss/1.0/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:cc="http://web.resource.org/cc/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://pinboard.in">
    <title>Pinboard (earth2marsh)</title>
    <link>https://pinboard.in/u:earth2marsh/public/</link>
    <description>recent bookmarks from earth2marsh</description>
    <items>
      <rdf:Seq>	<rdf:li rdf:resource="https://surfingcomplexity.blog/2024/12/14/quick-takes-on-the-recent-openai-public-incident-write-up/"/>
	<rdf:li rdf:resource="https://mintlify.com/"/>
	<rdf:li rdf:resource="https://cloud.withgoogle.com/next/sf/sessions?session=API102#business-application-platform"/>
	<rdf:li rdf:resource="https://stoplight.io/studio/"/>
	<rdf:li rdf:resource="https://blog.twitter.com/official/en_us/topics/product/2018/investing-in-the-best-twitter-experience-for-you.html"/>
	<rdf:li rdf:resource="https://twitter.com/i/web/status/1042879221784170497"/>
	<rdf:li rdf:resource="https://caseysoftware.com/blog/three-styles-api-documentation"/>
	<rdf:li rdf:resource="https://thenextweb.com/contributors/2017/12/03/heres-choose-sdk-api/"/>
	<rdf:li rdf:resource="http://antirez.com/news/107"/>
	<rdf:li rdf:resource="http://www.perspectiveapi.com/"/>
	<rdf:li rdf:resource="https://openapis.org/news/blogs/2016/10/tdc-structural-improvements-explaining-30-spec-part-2"/>
	<rdf:li rdf:resource="http://apievangelist.com/2016/09/12/api-stylebook-a-collections-of-resources-for-api-designers/"/>
	<rdf:li rdf:resource="https://github.com/paypal/api-standards/blob/master/api-style-guide.md"/>
	<rdf:li rdf:resource="http://www.slideshare.net/jmusser/why-api-ops-is-the-next-wave-of-devops-62440606/49"/>
	<rdf:li rdf:resource="http://www.slideshare.net/launchany/designing-apis-and-microservices-using-domaindriven-design"/>
	<rdf:li rdf:resource="https://en.wikipedia.org/wiki/Hungarian_notation"/>
	<rdf:li rdf:resource="https://ardielle.github.io/"/>
	<rdf:li rdf:resource="https://github.com/ardielle/ardielle-common"/>
	<rdf:li rdf:resource="http://apieconomist.com/blog//jennifer-rondeau-on-the-mix-of-grammar-and-tech-in-api-documentation"/>
	<rdf:li rdf:resource="https://groups.google.com/forum/#!msg/siren-hypermedia/lmPrsrDBhVE/OF4orjkGAwAJ"/>
	<rdf:li rdf:resource="https://groups.google.com/forum/#!topic/api-craft/n2Efmju5nLM"/>
	<rdf:li rdf:resource="http://nordicapis.com/core-principles-api-management/"/>
	<rdf:li rdf:resource="https://medium.com/@matryer/introducing-silk-markdown-driven-api-tests-1f8cfb0ef99a"/>
	<rdf:li rdf:resource="https://www.owasp.org/index.php/Top_10_2010-A4-Insecure_Direct_Object_References"/>
	<rdf:li rdf:resource="http://mmikowski.github.io/the_lie/"/>
	<rdf:li rdf:resource="https://github.com/JimRobs/syno"/>
	<rdf:li rdf:resource="http://www.infoq.com/presentations/API-Business-Models"/>
	<rdf:li rdf:resource="http://swapi.co/"/>
	<rdf:li rdf:resource="https://github.com/apigee-127/swagger-tools/blob/master/docs/QuickStart.md"/>
	<rdf:li rdf:resource="http://blog.mention.com/what-we-can-learn-from-the-yo-api/"/>
	<rdf:li rdf:resource="http://www.deployd.com/"/>
	<rdf:li rdf:resource="http://stackoverflow.com/questions/19623339/is-a-list-array-valid-json"/>
	<rdf:li rdf:resource="https://github.com/scripting/fargoPublisher/blob/master/README.md"/>
	<rdf:li rdf:resource="https://restberry.com/#/#top"/>
	<rdf:li rdf:resource="https://www.leftronic.com/blog/five-hair-pulling-apis/"/>
	<rdf:li rdf:resource="http://brandur.org/sdk"/>
	<rdf:li rdf:resource="https://groups.google.com/forum/m/#!topic/foursquare-api/X60gF5Zi0k4"/>
	<rdf:li rdf:resource="http://byterot.blogspot.com/2013/10/api-layer-and-its-responsibilities-rest-viewpoint-webapi-csds-aspnetwebapi.html?m=1"/>
	<rdf:li rdf:resource="http://www.infoq.com/news/2013/12/api-versioning"/>
	<rdf:li rdf:resource="https://npmjs.org/package/fakeson"/>
	<rdf:li rdf:resource="http://www.mocky.io/"/>
	<rdf:li rdf:resource="http://whatismyipaddress.com/api"/>
	<rdf:li rdf:resource="http://doc.qt.digia.com/qq/qq13-apis.html"/>
	<rdf:li rdf:resource="https://github.com/peej/tonic"/>
	<rdf:li rdf:resource="http://apimetrics.io/features/"/>
	<rdf:li rdf:resource="https://www.owasp.org/index.php/REST_Security_Cheat_Sheet"/>
	<rdf:li rdf:resource="http://developer.github.com/v3/media/#api-v3-media-type-and-the-future"/>
	<rdf:li rdf:resource="https://pinboard.in/u:arnaud/t:api/"/>
	<rdf:li rdf:resource="http://tech.blog.box.com/2012/12/going-beyond-oauth2-byod-in-the-enterprise/"/>
	<rdf:li rdf:resource="http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0128.html"/>
	<rdf:li rdf:resource="http://tech.blog.box.com/2013/04/get-developer-hugs-with-rich-error-handling-in-your-api/"/>
	<rdf:li rdf:resource="http://www.mnot.net/blog/2013/05/15/http_problem"/>
	<rdf:li rdf:resource="http://humanapi.co/"/>
	<rdf:li rdf:resource="http://flippinawesome.org/2013/09/23/easy-api-scaffolding-with-simple-api-and-node-js/"/>
	<rdf:li rdf:resource="http://codebetter.com/howarddierking/2013/09/12/versioning-restful-services-v2/"/>
	<rdf:li rdf:resource="https://news.ycombinator.com/item?id=6361662"/>
	<rdf:li rdf:resource="http://docs.oocharts.com/"/>
	<rdf:li rdf:resource="https://mathieu.fenniak.net/the-api-checklist/"/>
	<rdf:li rdf:resource="https://github.com/trentm/restdown"/>
	<rdf:li rdf:resource="http://friends.diy.org/"/>
	<rdf:li rdf:resource="https://tools.ietf.org/html/draft-nottingham-http-problem-03"/>
	<rdf:li rdf:resource="http://www.garethshapiro.com/item/simple-objective-c-api-service"/>
	<rdf:li rdf:resource="http://www4.in.tum.de/~blanchet/api-design.pdf"/>
	<rdf:li rdf:resource="http://apiaxle.com/"/>
	<rdf:li rdf:resource="http://dev.w3.org/2009/dap/ReSpec.js/documentation.html#webidl-support"/>
	<rdf:li rdf:resource="https://mathieu.fenniak.net/stop-designing-fragile-web-apis/"/>
	<rdf:li rdf:resource="https://api.pinboard.in/v1/posts/all"/>
	<rdf:li rdf:resource="https://www.balancedpayments.com/"/>
	<rdf:li rdf:resource="https://github.com/linkedin/rest.li/wiki/Rest.li-.restspec.json-Format"/>
	<rdf:li rdf:resource="https://developers.facebook.com/roadmap/change-policy/"/>
      </rdf:Seq>
    </items>
  </channel><item rdf:about="https://surfingcomplexity.blog/2024/12/14/quick-takes-on-the-recent-openai-public-incident-write-up/">
    <title>Quick takes on the recent OpenAI public incident write-up – Surfing Complexity</title>
    <dc:date>2024-12-15T06:34:19+00:00</dc:date>
    <link>https://surfingcomplexity.blog/2024/12/14/quick-takes-on-the-recent-openai-public-incident-write-up/</link>
    <dc:creator>earth2marsh</dc:creator><description><![CDATA[<blockquote>OpenAI recently published a public writeup for an incident they had on December 11, and there are lots of good details in here! Here are some of my off-the-cuff observations:

Saturation
With thousands of nodes performing these operations simultaneously, the Kubernetes API servers became overwhelmed, taking down the Kubernetes control plane in most of our large clusters.</blockquote>]]></description>
<dc:subject>openai outage kubernetes complex systems failures api</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:4839039ca20c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:openai"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:outage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:kubernetes"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:complex"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:systems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:failures"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://mintlify.com/">
    <title>Mintlify - The modern standard for documentation</title>
    <dc:date>2024-05-26T07:27:36+00:00</dc:date>
    <link>https://mintlify.com/</link>
    <dc:creator>earth2marsh</dc:creator><description><![CDATA[so... a readme competitor? ]]></description>
<dc:subject>api docs documentation service</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:79ab787a0d50/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:docs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:documentation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:service"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://cloud.withgoogle.com/next/sf/sessions?session=API102#business-application-platform">
    <title>Google Cloud Next ’20: OnAir | Weekly, on Tuesday at 9 AM PDT</title>
    <dc:date>2020-09-03T01:13:05+00:00</dc:date>
    <link>https://cloud.withgoogle.com/next/sf/sessions?session=API102#business-application-platform</link>
    <dc:creator>earth2marsh</dc:creator><description><![CDATA[Why is developer engagement critical to an API program? Join me with @evansche as we discuss HP's approach to developer experience and what they learned along their journey. "Enterprise: Digital Transformation via Developer Engagement" #GoogleCloudNext   ]]></description>
<dc:subject>GoogleCloudNext DigitalTransformation API devex</dc:subject>
<dc:source>https://twitter.com/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:63d6ead27029/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:GoogleCloudNext"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:DigitalTransformation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:API"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:devex"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://stoplight.io/studio/">
    <title>Stoplight Studio | OpenAPI Design, Planning &amp; Modeling Tool</title>
    <dc:date>2019-09-10T23:22:27+00:00</dc:date>
    <link>https://stoplight.io/studio/</link>
    <dc:creator>earth2marsh</dc:creator><description><![CDATA[meant to pin this before...]]></description>
<dc:subject>api design tools</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:e315dc40fdaa/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:tools"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://blog.twitter.com/official/en_us/topics/product/2018/investing-in-the-best-twitter-experience-for-you.html">
    <title>Investing in the best Twitter experience for you</title>
    <dc:date>2018-11-19T19:44:21+00:00</dc:date>
    <link>https://blog.twitter.com/official/en_us/topics/product/2018/investing-in-the-best-twitter-experience-for-you.html</link>
    <dc:creator>earth2marsh</dc:creator><description><![CDATA[""]]></description>
<dc:subject>twitter api strategy timeline</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:5ed1c29137c1/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:twitter"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:strategy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:timeline"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://twitter.com/i/web/status/1042879221784170497">
    <title>Twitter</title>
    <dc:date>2018-09-20T21:15:56+00:00</dc:date>
    <link>https://twitter.com/i/web/status/1042879221784170497</link>
    <dc:creator>earth2marsh</dc:creator><description><![CDATA[RT @OpenApiSpec: Hey #API community! @manp is moderating a panel @APIStrat in Nashville next week on the future of the #OASv3 with… ]]></description>
<dc:subject>API OASv3</dc:subject>
<dc:source>https://twitter.com/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:a297b29915a0/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:API"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:OASv3"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://caseysoftware.com/blog/three-styles-api-documentation">
    <title>The Three Styles of API Documentation - Caseysoftware</title>
    <dc:date>2018-03-06T15:08:39+00:00</dc:date>
    <link>https://caseysoftware.com/blog/three-styles-api-documentation</link>
    <dc:creator>earth2marsh</dc:creator><description><![CDATA[Here's my strategy and thought process on #API #Documentation 

I'd love to hear yours]]></description>
<dc:subject>Documentation API</dc:subject>
<dc:source>https://twitter.com/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:f05e7087f01c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:Documentation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:API"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://thenextweb.com/contributors/2017/12/03/heres-choose-sdk-api/">
    <title>Here's how you choose between an SDK and an API</title>
    <dc:date>2017-12-03T23:23:59+00:00</dc:date>
    <link>https://thenextweb.com/contributors/2017/12/03/heres-choose-sdk-api/</link>
    <dc:creator>earth2marsh</dc:creator><description><![CDATA[SDKs are cake mixes. Don't need to know much about baking, just follow directions. 

"An SDK is like a box of cake mix. It has pre-built functionality that makes baking a cake faster and easier. You don’t necessarily even have to know much about, or have any experience, baking.

An API on the other hand is like a recipe used to bake a cake. It’s a set of instructions with room to be creative. You can get to the same end result, but without previous knowledge it’s much more difficult and may have some unintended consequences. Additionally, you can get cake mix geared towards cupcakes, pancakes, or even in different flavors; the same way each SDK is a software toolset specially crafted for a given language or platform to interact with the underlying services."]]></description>
<dc:subject>apis sdks api skd choices comparison tradeoff</dc:subject>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:700c6dbfeeaa/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:apis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:sdks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:skd"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:choices"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:comparison"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:tradeoff"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://antirez.com/news/107">
    <title>Programmers are not different, they need simple UIs. - &lt;antirez&gt;</title>
    <dc:date>2017-03-03T02:44:05+00:00</dc:date>
    <link>http://antirez.com/news/107</link>
    <dc:creator>earth2marsh</dc:creator><dc:subject>programming design api APIs craft</dc:subject>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:8428f718ff09/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:APIs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:craft"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.perspectiveapi.com/">
    <title>Perspective</title>
    <dc:date>2017-02-23T21:36:22+00:00</dc:date>
    <link>http://www.perspectiveapi.com/</link>
    <dc:creator>earth2marsh</dc:creator><description><![CDATA["Perspective is in the early days of research and development. You can request an API key (rolling out through 2017) or sign up to get more information.

Perspective was created by Jigsaw and Google’s Counter Abuse Technology team in a collaborative research project called Conversation-AI. We are also open sourcing experiments, models, and research data to explore the strengths and weaknesses (e.g. potential unintended biases) of using machine learning as a tool for online discussion. You can learn more about our values, goals, and emerging experiments on our Github page. For more Google machine learning tools, check out TensorFlow and the Cloud ML Platform."]]></description>
<dc:subject>google apis api abuse content sentiment moderation toxicity</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:31822d4e6b23/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:apis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:abuse"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:content"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:sentiment"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:moderation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:toxicity"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://openapis.org/news/blogs/2016/10/tdc-structural-improvements-explaining-30-spec-part-2">
    <title>TDC: Structural Improvements: explaining the 3.0 spec, part 2 | Open API Initiative</title>
    <dc:date>2016-10-04T18:31:36+00:00</dc:date>
    <link>https://openapis.org/news/blogs/2016/10/tdc-structural-improvements-explaining-30-spec-part-2</link>
    <dc:creator>earth2marsh</dc:creator><description><![CDATA[RT @OpenApiSpec: What can you expect to see in the next version of the @OpenApiSpec? Get the updated from @darrel_miller  #API]]></description>
<dc:subject>API</dc:subject>
<dc:source>https://twitter.com/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:b08825ba0514/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:API"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://apievangelist.com/2016/09/12/api-stylebook-a-collections-of-resources-for-api-designers/">
    <title>API Stylebook: A Collections Of Resources For API Designers</title>
    <dc:date>2016-09-13T06:27:19+00:00</dc:date>
    <link>http://apievangelist.com/2016/09/12/api-stylebook-a-collections-of-resources-for-api-designers/</link>
    <dc:creator>earth2marsh</dc:creator><description><![CDATA[via API Evangelist]]></description>
<dc:subject>IFTTT Feedly apis design api guidelines style styles</dc:subject>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:83810ca3b955/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:IFTTT"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:Feedly"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:apis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:guidelines"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:style"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:styles"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/paypal/api-standards/blob/master/api-style-guide.md">
    <title>api-standards/api-style-guide.md at master · paypal/api-standards</title>
    <dc:date>2016-08-26T23:25:51+00:00</dc:date>
    <link>https://github.com/paypal/api-standards/blob/master/api-style-guide.md</link>
    <dc:creator>earth2marsh</dc:creator><description><![CDATA[""]]></description>
<dc:subject>paypal api standards style guide</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:b934ddb8689c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:paypal"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:style"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:guide"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.slideshare.net/jmusser/why-api-ops-is-the-next-wave-of-devops-62440606/49">
    <title>Why API Ops is the Next Wave of DevOps</title>
    <dc:date>2016-05-27T23:54:42+00:00</dc:date>
    <link>http://www.slideshare.net/jmusser/why-api-ops-is-the-next-wave-of-devops-62440606/49</link>
    <dc:creator>earth2marsh</dc:creator><description><![CDATA[""]]></description>
<dc:subject>api apis lifecycle musser</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:edd37fdfaf5c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:apis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:lifecycle"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:musser"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.slideshare.net/launchany/designing-apis-and-microservices-using-domaindriven-design">
    <title>Designing APIs and Microservices Using Domain-Driven Design</title>
    <dc:date>2016-05-27T18:38:57+00:00</dc:date>
    <link>http://www.slideshare.net/launchany/designing-apis-and-microservices-using-domaindriven-design</link>
    <dc:creator>earth2marsh</dc:creator><dc:subject>apis design api microservices domain driven development</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:70872324ee06/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:apis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:microservices"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:domain"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:driven"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:development"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://en.wikipedia.org/wiki/Hungarian_notation">
    <title>Hungarian notation - Wikipedia, the free encyclopedia</title>
    <dc:date>2016-05-18T16:24:16+00:00</dc:date>
    <link>https://en.wikipedia.org/wiki/Hungarian_notation</link>
    <dc:creator>earth2marsh</dc:creator><description><![CDATA[1. Don’t use two fields to describe the same data when one will do. (Resist the redundant boolean)
2. Just say no to Hungarian Notation.

Linus says:
> Encoding the type of a function into the name (so-called Hungarian notation) is brain damaged—the compiler knows the types anyway and can check those, and it only confuses the programmer.

Re: https://www.hl7.org/fhir/patient.html]]></description>
<dc:subject>naming variables api apis design bestpractices</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:0e71c5450109/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:naming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:variables"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:apis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:bestpractices"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://ardielle.github.io/">
    <title>RDL - Resource Description Language</title>
    <dc:date>2016-05-05T19:35:33+00:00</dc:date>
    <link>https://ardielle.github.io/</link>
    <dc:creator>earth2marsh</dc:creator><description><![CDATA["RDL is a machine-readable description of a schema that describes data types, as well as resources using those types. Such a schema can be used to describe HTTP web services, as well as serve as the source of truth for data encoding mechanisms like Protocol Buffers and Avro, as well as augment JSON and other encoding schemes by providing data validation.

Types are defined by deriving from an already defined type. Every type is thus derived (perhaps indirectly) from a primitive base type. For each base type various different options may be available to further restrict the type.

"]]></description>
<dc:subject>apis descriptions api description format</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:0109913829b2/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:apis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:descriptions"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:description"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:format"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/ardielle/ardielle-common">
    <title>ardielle/ardielle-common</title>
    <dc:date>2016-05-05T19:34:55+00:00</dc:date>
    <link>https://github.com/ardielle/ardielle-common</link>
    <dc:creator>earth2marsh</dc:creator><description><![CDATA["RDL is a machine-readable description of a schema that describes data types, and resources and data tables using those types. Such a schema can be used to describe HTTP web services and storage tables, as well as serve as the source of truth for data encoding mechanisms like Protocol Buffers and Avro, as well as augment JSON and other encoding schemes by providing data validation.

RDL is particularly useful in describing REST-based APIs, providing a first class artifact that describes the API in an implementation-independent manner."]]></description>
<dc:subject>apis api descriptions description format</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:fe7aefc82dd9/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:apis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:descriptions"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:description"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:format"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://apieconomist.com/blog//jennifer-rondeau-on-the-mix-of-grammar-and-tech-in-api-documentation">
    <title>Jennifer Rondeau on the mix of grammar and tech in API documentation — The API Economist</title>
    <dc:date>2016-04-20T01:27:54+00:00</dc:date>
    <link>http://apieconomist.com/blog//jennifer-rondeau-on-the-mix-of-grammar-and-tech-in-api-documentation</link>
    <dc:creator>earth2marsh</dc:creator><description><![CDATA[""]]></description>
<dc:subject>api apis documentation people language art</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:a02b2392db88/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:apis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:documentation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:people"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:language"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:art"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://groups.google.com/forum/#!msg/siren-hypermedia/lmPrsrDBhVE/OF4orjkGAwAJ">
    <title>Follow up wrt domains, interfaces, and CRUD... - Google Groups</title>
    <dc:date>2016-03-23T16:51:06+00:00</dc:date>
    <link>https://groups.google.com/forum/#!msg/siren-hypermedia/lmPrsrDBhVE/OF4orjkGAwAJ</link>
    <dc:creator>earth2marsh</dc:creator><description><![CDATA["Model Separation: As use case complexity increases, the benefits of model separation increase. Logically, these are all different representations: data model, domain model, application model, reporting model. While this may be true, it might not make sense to separate all these in code if your use cases are very simple (CRUD-ish, for instance). The most complex use cases will use all of the above.

The following represents a growth path as use case complexity increases.

API Over Data Model: If you're looking for an API over data, check out OData[1], as Glenn suggested. An alternative that I promote from time to time is Collection+JSON[2]. OData has good support on the .NET Framework. I'm not sure about Collection+JSON. This is great when there is little to no behavior happening behind the scenes and you really need full-featured querying with CRUD.

API Over Domain Model: Designs in this arena may utilize some kind of ORM (Entity Framework, NHibernate, etc.) to hydrate "business"-layer objects that contain behavior specific to the problem domain of your application. Look to Domain Driven Design[3] for good pointers here. There's a step up here when your complexity starts to grow. It's common to start separating how reads are handled from writes. CQRS[4] provides lots of good guidance in this space. Without CQRS, an API will often use property getters of the Domain Model to build API responses. This is already the start of a leak in your Domain Model, which may lead to...

API Over Application Model: It may make sense to derive an Application Model from a Domain Model. When resources are modified in your API, the changes typically route through the Domain Model. When resource representations are fetched, they may be reading from a denormalized data store (document databases start working really well here) that has pre-populated application-specific models to serve through your API.

API Over Reporting Model: This is almost a parallel evolution with the the API Over Application Model concept. The model being served might be coming from denormalized data. This is typically read-only and may look more like API Over Data Model in implementation. Complex analytics over this is a whole different beast."]]></description>
<dc:subject>kevin_swiber apis api design models modeling data</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:ef8e80cfbb22/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:kevin_swiber"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:apis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:models"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:modeling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:data"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://groups.google.com/forum/#!topic/api-craft/n2Efmju5nLM">
    <title>PUT and update object - Google Groups</title>
    <dc:date>2016-03-23T15:10:00+00:00</dc:date>
    <link>https://groups.google.com/forum/#!topic/api-craft/n2Efmju5nLM</link>
    <dc:creator>earth2marsh</dc:creator><description><![CDATA["Your storage model is not your object model is not your resource model is not your representation model." 
"MY DATA MODEL IS NOT MY OBJECT MODEL
first, the data model (SQL, DocStore, FileSystem) is indepdendent of the object model in the program. for example, i might store customer information (including contact info, financial profile, and order history) in a database. and i might have an object model in my code that includes a customerSummary object. this customerSummary is not a data table. it is made up of details from each of the three data tables, tho.

MY OBJECT MODEL IS NOT MY RESOURCE MODEL
my HTTP resources might take into account the *context* of the user (e.g. visitor, customer, sales rep, admin) and offer different resources for each of them that exposes select customer data. e.g. the /public/customers/ resource might show a list of customer names only with a link to see detail if security context supports that. and the /sales/customer/ resource might list each customer along with recent order history and links to contact that customer directly, update the order history, etc. and the /private/customer/ resource might list only customer information that should be seen by the logged in customer (along with pointers to order history, the ability to start a new order, make a sales inquiry, etc.  none of these resources exist in the internal programming object model -- they are, however, aggregates of a handful of internal objects.

MY RESOURCE MODEL IS NOT MY REPRESENTATION MODEL
my HTTP resources might support content-negotiation for responses. for example, my customers might be able to request their order history (/private/customer/orders/) in CSV format or the standard HTML display. the HTML version might first show summaries of each order w/ a link to details of each. But the CSV response might show all the details in a single listing (listing order lines w/ orderid to show the relationships, etc.).

the point to all this is that HTTP only has something to say about the last two elements (RESOURCE and REPRESENTATION) and when HTTP says PUT is for replacing a resource that may have no direct correlation to any single internal OBJECT or DATA-RECORD. and there might even be a case where executing a PUT on a CSV representation of a resource will include different data elements than an HTML representation of that same resource."]]></description>
<dc:subject>PUT verbs api apis design objects resources</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:7f527112f74a/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:PUT"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:verbs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:apis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:objects"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:resources"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://nordicapis.com/core-principles-api-management/">
    <title>The Core Principles of API Management | Nordic APIs |</title>
    <dc:date>2016-03-14T23:03:18+00:00</dc:date>
    <link>http://nordicapis.com/core-principles-api-management/</link>
    <dc:creator>earth2marsh</dc:creator><description><![CDATA[highly registry based, but not a terrible overview]]></description>
<dc:subject>api apis management</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:1887ec1833e6/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:apis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:management"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://medium.com/@matryer/introducing-silk-markdown-driven-api-tests-1f8cfb0ef99a">
    <title>Introducing Silk — Medium</title>
    <dc:date>2016-03-01T16:44:52+00:00</dc:date>
    <link>https://medium.com/@matryer/introducing-silk-markdown-driven-api-tests-1f8cfb0ef99a</link>
    <dc:creator>earth2marsh</dc:creator><dc:subject>API APIs documentation tests markdown</dc:subject>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:76e78d27c20c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:API"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:APIs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:documentation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:tests"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:markdown"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.owasp.org/index.php/Top_10_2010-A4-Insecure_Direct_Object_References">
    <title>Top 10 2010-A4-Insecure Direct Object References - OWASP</title>
    <dc:date>2016-02-29T19:07:45+00:00</dc:date>
    <link>https://www.owasp.org/index.php/Top_10_2010-A4-Insecure_Direct_Object_References</link>
    <dc:creator>earth2marsh</dc:creator><description><![CDATA["The best way to find out if an application is vulnerable to insecure direct object references is to verify that all object references have appropriate defenses. To achieve this, consider:

For direct references to restricted resources, the application needs to verify the user is authorized to access the exact resource they have requested.
If the reference is an indirect reference, the mapping to the direct reference must be limited to values authorized for the current user.
Code review of the application can quickly verify whether either approach is implemented safely. Testing is also effective for identifying direct object references and whether they are safe. Automated tools typically do not look for such flaws because they cannot recognize what requires protection or what is safe or unsafe."]]></description>
<dc:subject>api design objects threats security resources owasp</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:dbcd716122b6/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:objects"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:threats"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:security"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:resources"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:owasp"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://mmikowski.github.io/the_lie/">
    <title>RESTful APIs, the big lie – Michael S. Mikowski – SPA (UI/UX/server) architect and author</title>
    <dc:date>2015-08-11T15:39:40+00:00</dc:date>
    <link>http://mmikowski.github.io/the_lie/</link>
    <dc:creator>earth2marsh</dc:creator><description><![CDATA[It's like SOAP! But with JSON!]]></description>
<dc:subject>rest apis API design json</dc:subject>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:725f8eaf2268/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:rest"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:apis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:API"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:json"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/JimRobs/syno">
    <title>JimRobs/syno · GitHub</title>
    <dc:date>2015-05-26T08:31:27+00:00</dc:date>
    <link>https://github.com/JimRobs/syno</link>
    <dc:creator>earth2marsh</dc:creator><description><![CDATA[Github Stars RSS feed Simple Node.js wrapper and CLI for Synology DSM REST API.]]></description>
<dc:subject>IFTTT github synology apis api nodejs node</dc:subject>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:fe426b5eeb03/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:IFTTT"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:github"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:synology"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:apis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:nodejs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:node"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.infoq.com/presentations/API-Business-Models">
    <title>API Business Models. 20 Models in 20 Minutes</title>
    <dc:date>2015-03-26T18:24:37+00:00</dc:date>
    <link>http://www.infoq.com/presentations/API-Business-Models</link>
    <dc:creator>earth2marsh</dc:creator><dc:subject>models business management api musser john_musser</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:8d769246f21f/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:models"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:business"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:management"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:musser"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:john_musser"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://swapi.co/">
    <title>SWAPI - The Star Wars API</title>
    <dc:date>2014-12-17T01:37:53+00:00</dc:date>
    <link>http://swapi.co/</link>
    <dc:creator>earth2marsh</dc:creator><description><![CDATA[""]]></description>
<dc:subject>starwars api apis</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:8e0744958148/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:starwars"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:apis"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/apigee-127/swagger-tools/blob/master/docs/QuickStart.md">
    <title>swagger-tools/QuickStart.md at master · apigee-127/swagger-tools · GitHub</title>
    <dc:date>2014-09-23T20:56:56+00:00</dc:date>
    <link>https://github.com/apigee-127/swagger-tools/blob/master/docs/QuickStart.md</link>
    <dc:creator>earth2marsh</dc:creator><description><![CDATA[RT @whitlockjc: Ever wanted to try swagger-tools but didn't know how?  Here is a Quick Start Guide:  #Swagger #OSS #API]]></description>
<dc:subject>API OSS Swagger</dc:subject>
<dc:source>https://twitter.com/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:e7df9b54b64a/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:API"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:OSS"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:Swagger"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://blog.mention.com/what-we-can-learn-from-the-yo-api/">
    <title>What We Can Learn From the Yo API – The Mention Blog</title>
    <dc:date>2014-07-23T22:15:01+00:00</dc:date>
    <link>http://blog.mention.com/what-we-can-learn-from-the-yo-api/</link>
    <dc:creator>earth2marsh</dc:creator><description><![CDATA[""]]></description>
<dc:subject>yo api apis design simplicity</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:421b8b7a2ade/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:yo"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:apis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:simplicity"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.deployd.com/">
    <title>Deployd</title>
    <dc:date>2014-06-25T15:10:20+00:00</dc:date>
    <link>http://www.deployd.com/</link>
    <dc:creator>earth2marsh</dc:creator><description><![CDATA[build APIs using node]]></description>
<dc:subject>tools development app api mobile</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:54cf67e4f7f7/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:tools"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:development"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:app"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:mobile"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://stackoverflow.com/questions/19623339/is-a-list-array-valid-json">
    <title>javascript - Is a list/array valid JSON? - Stack Overflow</title>
    <dc:date>2014-05-05T22:00:06+00:00</dc:date>
    <link>http://stackoverflow.com/questions/19623339/is-a-list-array-valid-json</link>
    <dc:creator>earth2marsh</dc:creator><description><![CDATA[On whether a naked array should be returned at all…

"for an API, you should always prefer the second form. The reason is that it gives you a path for expansion of your API.

For example, if you have an API getUsersInGroup which returns an array of user objects, and later you decide you want to include, say, some aggregate statistics about the users being returned, there's no easy way to do that without breaking existing clients (or including lots of redundant data in each user object). If you use an object, you simply add another field to the object which is silently ignored by clients on a previous version of the API.

In short, try to avoid primitives wherever possible in your API, except obviously as values inside objects."]]></description>
<dc:subject>api apis design arrays json patterns stackoverflow</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:a2c5ab882d0f/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:apis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:arrays"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:json"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:patterns"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:stackoverflow"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/scripting/fargoPublisher/blob/master/README.md">
    <title>Fargo Publisher</title>
    <dc:date>2014-03-08T16:12:39+00:00</dc:date>
    <link>https://github.com/scripting/fargoPublisher/blob/master/README.md</link>
    <dc:creator>earth2marsh</dc:creator><dc:subject>static HTML publishing api apis Dave_Winer</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:a13381d09155/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:static"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:HTML"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:publishing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:apis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:Dave_Winer"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://restberry.com/#/#top">
    <title>Restberry · Manage your RESTful APIs</title>
    <dc:date>2014-02-17T21:07:28+00:00</dc:date>
    <link>https://restberry.com/#/#top</link>
    <dc:creator>earth2marsh</dc:creator><dc:subject>api documentation modeling apis mocking</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:a82333843fa1/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:documentation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:modeling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:apis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:mocking"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.leftronic.com/blog/five-hair-pulling-apis/">
    <title>The five most &quot;hair-pulling&quot; APIs » Leftronic Leftronic</title>
    <dc:date>2014-02-17T18:32:00+00:00</dc:date>
    <link>https://www.leftronic.com/blog/five-hair-pulling-apis/</link>
    <dc:creator>earth2marsh</dc:creator><dc:subject>api apis design mistakes analytics sins</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:95bf231766e2/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:apis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:mistakes"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:analytics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:sins"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://brandur.org/sdk">
    <title>Why I Don't Want Your SDK in Production</title>
    <dc:date>2014-02-05T16:01:17+00:00</dc:date>
    <link>http://brandur.org/sdk</link>
    <dc:creator>earth2marsh</dc:creator><description><![CDATA[Where might this be different? Mobile …]]></description>
<dc:subject>sdk APIs development sdks api</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:6cbf427f7bf6/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:sdk"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:APIs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:development"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:sdks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://groups.google.com/forum/m/#!topic/foursquare-api/X60gF5Zi0k4">
    <title>Requiring a Version in the Foursquare API - Google Groups</title>
    <dc:date>2014-01-29T23:08:15+00:00</dc:date>
    <link>https://groups.google.com/forum/m/#!topic/foursquare-api/X60gF5Zi0k4</link>
    <dc:creator>earth2marsh</dc:creator><description><![CDATA[An anti pattern IMO]]></description>
<dc:subject>APIs api design patterns versions versioning foursquare query</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:ead28e4ba3b8/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:APIs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:patterns"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:versions"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:versioning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:foursquare"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:query"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://byterot.blogspot.com/2013/10/api-layer-and-its-responsibilities-rest-viewpoint-webapi-csds-aspnetwebapi.html?m=1">
    <title>Byte Rot: API Layer and its responsibilities - a REST viewpoint</title>
    <dc:date>2013-12-10T04:23:08+00:00</dc:date>
    <link>http://byterot.blogspot.com/2013/10/api-layer-and-its-responsibilities-rest-viewpoint-webapi-csds-aspnetwebapi.html?m=1</link>
    <dc:creator>earth2marsh</dc:creator><description><![CDATA[""]]></description>
<dc:subject>APIs API layer soa soap rest</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:ed637842ec8e/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:APIs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:API"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:layer"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:soa"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:soap"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:rest"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.infoq.com/news/2013/12/api-versioning">
    <title>The Costs of Versioning an API</title>
    <dc:date>2013-12-05T18:22:12+00:00</dc:date>
    <link>http://www.infoq.com/news/2013/12/api-versioning</link>
    <dc:creator>earth2marsh</dc:creator><description><![CDATA[interesting approach. ]]></description>
<dc:subject>versioning api design</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:3f284580601e/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:versioning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:design"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://npmjs.org/package/fakeson">
    <title>fakeson</title>
    <dc:date>2013-12-03T17:45:06+00:00</dc:date>
    <link>https://npmjs.org/package/fakeson</link>
    <dc:creator>earth2marsh</dc:creator><description><![CDATA[""]]></description>
<dc:subject>api mocking mocks apis rest</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:4f845c8b8883/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:mocking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:mocks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:apis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:rest"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.mocky.io/">
    <title>Mocky: Real HTTP mocking</title>
    <dc:date>2013-12-03T17:42:57+00:00</dc:date>
    <link>http://www.mocky.io/</link>
    <dc:creator>earth2marsh</dc:creator><description><![CDATA[""]]></description>
<dc:subject>mock http api mocking</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:b97f97224d90/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:mock"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:http"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:mocking"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://whatismyipaddress.com/api">
    <title>WhatIsMyIPAddress.com API</title>
    <dc:date>2013-12-02T19:59:22+00:00</dc:date>
    <link>http://whatismyipaddress.com/api</link>
    <dc:creator>earth2marsh</dc:creator><description><![CDATA["We provide a specific page that returns just the IP address of the device making the request on http://bot.whatismyipaddress.com. You are free to query that server but please limit queries to no more than once per five minutes. While rate limiting is currently not in place if the service is abused it will be. Please do not attempt to obtain the IP address by querying the homepage of our website. Strict rate limiting is enforced there and the page is more bandwidth and processor intensive than bot.whatismyipaddress.com."]]></description>
<dc:subject>ip addresses api discovery</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:fb1422e29023/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:ip"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:addresses"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:discovery"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://doc.qt.digia.com/qq/qq13-apis.html">
    <title>Designing Qt-Style C++ APIs</title>
    <dc:date>2013-11-21T02:00:00+00:00</dc:date>
    <link>http://doc.qt.digia.com/qq/qq13-apis.html</link>
    <dc:creator>earth2marsh</dc:creator><description><![CDATA[""]]></description>
<dc:subject>api apis design</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:9284115f93d9/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:apis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:design"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/peej/tonic">
    <title>peej/tonic</title>
    <dc:date>2013-11-21T01:33:43+00:00</dc:date>
    <link>https://github.com/peej/tonic</link>
    <dc:creator>earth2marsh</dc:creator><description><![CDATA["PHP library/framework for building Web apps while respecting the 5 principles of RESTful design.

Give every "thing" an ID (aka URIs)
Link things together (HATEOAS)
Use standard methods (aka the standard interface)
Resources with multiple representations (aka standard document formats)
Communicate statelessly"]]></description>
<dc:subject>api rest framework php design</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:a06db091dd17/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:rest"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:framework"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:php"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:design"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://apimetrics.io/features/">
    <title>Features | APImetrics</title>
    <dc:date>2013-11-16T00:42:31+00:00</dc:date>
    <link>http://apimetrics.io/features/</link>
    <dc:creator>earth2marsh</dc:creator><description><![CDATA[space is getting crowded… API Science, Runscope Radar, Smart Bear]]></description>
<dc:subject>api apis monitoring</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:c53ffedc5824/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:apis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:monitoring"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.owasp.org/index.php/REST_Security_Cheat_Sheet">
    <title>REST Security Cheat Sheet - OWASP</title>
    <dc:date>2013-11-09T00:46:15+00:00</dc:date>
    <link>https://www.owasp.org/index.php/REST_Security_Cheat_Sheet</link>
    <dc:creator>earth2marsh</dc:creator><description><![CDATA[Hmm. Reads a bit dated to me.]]></description>
<dc:subject>cheatsheet rest security api apis</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:6a07ef4ab27f/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:cheatsheet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:rest"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:security"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:apis"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://developer.github.com/v3/media/#api-v3-media-type-and-the-future">
    <title>Custom Media Types | GitHub API</title>
    <dc:date>2013-11-05T00:37:15+00:00</dc:date>
    <link>http://developer.github.com/v3/media/#api-v3-media-type-and-the-future</link>
    <dc:creator>earth2marsh</dc:creator><description><![CDATA[""]]></description>
<dc:subject>api design github apis versioning mediatypes</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:f266578ed6bb/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:github"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:apis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:versioning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:mediatypes"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://pinboard.in/u:arnaud/t:api/">
    <title>Pinboard: bookmarks for arnaud tagged 'api'</title>
    <dc:date>2013-11-03T18:25:18+00:00</dc:date>
    <link>https://pinboard.in/u:arnaud/t:api/</link>
    <dc:creator>earth2marsh</dc:creator><description><![CDATA[""]]></description>
<dc:subject>pinboard api people apis</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:ff219832003a/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:pinboard"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:people"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:apis"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://tech.blog.box.com/2012/12/going-beyond-oauth2-byod-in-the-enterprise/">
    <title>Box Tech Blog » Going Beyond OAuth2: BYOD in the Enterprise</title>
    <dc:date>2013-10-25T13:06:23+00:00</dc:date>
    <link>http://tech.blog.box.com/2012/12/going-beyond-oauth2-byod-in-the-enterprise/</link>
    <dc:creator>earth2marsh</dc:creator><description><![CDATA["In order to connect an access token to a specific device, the client makes a request to the token endpoint by sending an extra parameter called ‘device_id’ using the “application/x-www-form-urlencoded” format with a character encoding of UTF-8 in the HTTP request entity-body. An example request in cURL for the authorization code grant looks like:

curl https://api.box.com/oauth2/token -d ‘grant_type=authorization_code&code={your_code}&client_id={your_client_id}&client_secret={your_client_secret}&device_id={authorized_device_id}&device_name={human_readable_device_name}’ -X POST

If you are using a refresh token to get a new access token, the refresh token grant also supports sending the device ID as follows:

curl https://api.box.com/oauth2/token -d ‘grant_type=refresh_token&refresh_token={valid refresh token}&client_id={your_client_id}&client_secret={your_client_secret}&device_id={authorized_device_id}&device_name={human_readable_device_name}’ -X POST

Device ID is an optional client specific alphanumeric string that should remain constant for the lifetime of the device. This string could be the (now deprecated) CFUUIDCreate library method in iOS. An alternative is to use the BPXLUUIDHandler project on GitHub. For Android, Settings.Secure#ANDROID_ID can be used. The device ID can be leveraged to restrict corporate data access of other devices such as laptops, as long as the device id does not change. An app can choose to leverage this functionality for improved security, especially in a trusted access enabled enterprise.

Device name is an optional parameter that can be used by enterprise admins to visually identify devices that currently have access to enterprise data.

Let us assume that an enterprise has authorized a device with id ’123′ access to access its data. All other oauth2 query parameters being valid, here is how device ID is consumed by Box’s OAuth2 authorization server for an enterprise that has enabled device pinning:

Incoming device idIs token request successful
120No
Device id missingNo
123Yes
You might wonder why Box does not check for a device ID when at the OAuth2 authorization endpoint. The reason for this is that a device that was authorized when an authorization code was issued to it may be unauthorized (due to an enterprise admin invalidating the device) when it requests an access token. Hence it is more secure to check for device identity at the tokens endpoint."]]></description>
<dc:subject>box api apis design authentication devices oauth</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:b5cfe772cdff/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:box"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:apis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:authentication"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:devices"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:oauth"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0128.html">
    <title>Why Multi-Status is a 2xx Response from Yaron Goland on 1999-02-14 (w3c-dist-auth@w3.org from January to March 1999)</title>
    <dc:date>2013-10-25T12:42:44+00:00</dc:date>
    <link>http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0128.html</link>
    <dc:creator>earth2marsh</dc:creator><description><![CDATA[Rationale for what WebDAV did with mixed errors. Mistake, IMO, but it was 1999…]]></description>
<dc:subject>multiple errors webdav api apis design</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:9211232b0260/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:multiple"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:errors"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:webdav"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:apis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:design"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://tech.blog.box.com/2013/04/get-developer-hugs-with-rich-error-handling-in-your-api/">
    <title>Box Tech Blog » Get developer hugs with rich error handling in your API</title>
    <dc:date>2013-10-25T12:35:39+00:00</dc:date>
    <link>http://tech.blog.box.com/2013/04/get-developer-hugs-with-rich-error-handling-in-your-api/</link>
    <dc:creator>earth2marsh</dc:creator><description><![CDATA["some best practices to follow when returning an error response (excluding HEAD requests):

Return an HTTP status code that closely matches the error condition
The Amazon S3 API is one particular example showcasing how HTTP status codes could be misused. It returns a 200 error with a body that contains an application-specific error code. To quote their documentation:

If the error occurs during the copy operation, the error response is embedded in the 200 OK response. This means that a 200 OK response can contain either a success or an error.

Doing this might cache a copy of the response and return it the next time the app does a GET for the same resource.

Return human-readable error messages
APIs are meant to be consumed by developers (and apps). While it’s essential to get HTTP status codes right, they are fairly coarse-grained and do not provide enough information to the developer. Consider the case where a developer tries to upload a file to Box and gets a 400-status code: Was the request body malformed? Was the parent folder ID missing? Having an error message immediately makes it clear what went wrong. Ensure that internal-only messages (such as database version or stack traces) are excluded. To get bonus points, localize the error messages.

Return machine-readable error codes
These are constants to indicate the error that happened. Usually they are exposed as strings (for example, ‘folder_name_already_used’ ) or integers. An app can consume the error codes (e.g., in a switch statement) to display dialogs that are relevant to the error condition. For instance, if the ‘folder_name_already_used’ error code is detected, the app can display a textbox with a “Rename” button that lets the client pick a different name for the folder.

Return the Invalid parameter name
Whenever possible, return the specific input parameter that the developer specified (or did not specify) that caused the API to choke on.

Set Location
This information is very useful for the developer to quickly identify the place that holds the erroneous piece of request. For REST APIs, location can be a URL, header or entity-body.

Provide a Help URL
If additional information to debug the error is available, include the link in the error response. The link destination, usually to a knowledge base, will provide more information about the error, often with suggested tips to resolve it. You might consider using the Link header with an extended relation type such as ‘api-help’ to communicate the help URL (since the RFC does not define a standard relation type for errors). Set any other response headers, if applicable."]]></description>
<dc:subject>api apis design http errors box bestpractices</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:8a0c915a520a/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:apis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:http"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:errors"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:box"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:bestpractices"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.mnot.net/blog/2013/05/15/http_problem">
    <title>mnot’s blog: Indicating Problems in HTTP APIs</title>
    <dc:date>2013-10-24T19:11:24+00:00</dc:date>
    <link>http://www.mnot.net/blog/2013/05/15/http_problem</link>
    <dc:creator>earth2marsh</dc:creator><description><![CDATA["Clients shouldn’t have to pick through 30 slightly different formats and implement parsers specific to each one; it’s a waste of energy. People creating APIs shouldn’t have to guess what a good format looks like, only running into problems down the road. And they certainly shouldn’t have to register new media types for “Fault” formats of every API they create.

So, a while back I decided to come up with a generic format for indicating the details of a problem encountered in using an HTTP-based API. The current draft has an example:

   HTTP/1.1 403 Forbidden
   Content-Type: application/api-problem+json
   Content-Language: en

   {
    "problemType": "http://example.com/probs/out-of-credit",
    "title": "You do not have enough credit.",
    "detail": "Your current balance is 30, but that costs 50.",
    "problemInstance": "http://example.net/account/12345/msgs/abc",
    "balance": 30,
    "accounts": ["http://example.net/account/12345",
                 "http://example.net/account/67890"]
   }
"]]></description>
<dc:subject>json http rest api apis design mnot errors</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:9bdfa0165f39/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:json"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:http"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:rest"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:apis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:mnot"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:errors"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://humanapi.co/">
    <title>human/api</title>
    <dc:date>2013-10-10T16:45:16+00:00</dc:date>
    <link>http://humanapi.co/</link>
    <dc:creator>earth2marsh</dc:creator><description><![CDATA[Lovely portal using Swagger]]></description>
<dc:subject>healthcare api data portal design example</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:2b0bdda78ee8/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:healthcare"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:data"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:portal"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:example"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://flippinawesome.org/2013/09/23/easy-api-scaffolding-with-simple-api-and-node-js/">
    <title>Easy API Scaffolding with Simple-API and Node.js | Flippin' Awesome</title>
    <dc:date>2013-09-23T14:39:53+00:00</dc:date>
    <link>http://flippinawesome.org/2013/09/23/easy-api-scaffolding-with-simple-api-and-node-js/</link>
    <dc:creator>earth2marsh</dc:creator><dc:subject>node nodejs mocking api design apis</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:a9ab51d990f0/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:node"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:nodejs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:mocking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:apis"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://codebetter.com/howarddierking/2013/09/12/versioning-restful-services-v2/">
    <title>Versioning RESTful Services v2 | Howard Dierking</title>
    <dc:date>2013-09-12T16:15:13+00:00</dc:date>
    <link>http://codebetter.com/howarddierking/2013/09/12/versioning-restful-services-v2/</link>
    <dc:creator>earth2marsh</dc:creator><description><![CDATA["Where this breaks down is that I cannot specify the accept type in the image tag, so how can I be sure that the server will default my request to image/jpg?

Further, If i wanted version 2, I cannot specify that either. So I feel like there might actually be some validity in using a version based uri scheme for these types of scenarios.

I agree.

In my original thinking, I was much more zealous about the promise of server-driven content negotiation than I am today. There are a few reasons my ideological shift away from the panacea of server-driven content negotiation based on the NuGet API v3 experience (really, it’s not just because Fielding avoids it – though I tend to agree with his reasoning).

Inconsistent support from caches
Different levels of support from clients with regard to their ability to manipulate the outgoing HTTP request
Lack of determinism for handling the response
Reliance on compute-bound service architectures
I think that the first 2 reasons are pretty well understood, so I’ll focus on the last 2."]]></description>
<dc:subject>versioning rest api apis design</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:d72b15660ffb/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:versioning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:rest"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:apis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:design"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://news.ycombinator.com/item?id=6361662">
    <title>If for some reason you can't or don't want to implement webhooks, at least make ... | Hacker News</title>
    <dc:date>2013-09-10T23:20:50+00:00</dc:date>
    <link>https://news.ycombinator.com/item?id=6361662</link>
    <dc:creator>earth2marsh</dc:creator><description><![CDATA["If for some reason you can't or don't want to implement webhooks, at least make sure you the GET endpoint for any object has a query param that supports fetching the most recently updated or created objects and supports pagination.
It sounds trivial, but you'd be surprised how many APIs don't support one or both of those features. When you're writing an API it might seem unnecessary to start (after all, who could ever have 1000s of <object>?), but if someone ends up polling your API frequently, having those two features can reduce a lot of unnecessary load for both you and the poller. And, of course, make sure you have an index on the created and/or updated dimensions.
That said, webhooks are terrific. Few things to consider when implementing them:
- Think carefully about the payload you send to the webhook. It's usually a good idea to send some related objects/data because many times when someone gets a webhook payload, that'll trigger calls to your API to get related information you could've reasonably sent them in the initial payload.
- You'll likely want to some way to keep track of errors so if an endpoint starts returning 404s or 500s you have a way to programmatically discard it after X failed attempts.
- In your docs, give sample, "real world" payloads developers can test against. It saves times over creating a RequestBin, pushing there, copying, cURLing, etc. (Remember, you can't set up a webhook to localhost.)
- A nice to have is some sort of retry capability with an exponential back-off. Servers go offline and if they get pushed webhook data then, those messages are lost. You could say, "tough, it's the consumer's responsibility," but if having all the data is important, most people will resort to polling. (Somewhat related, you'd be surprised how often the APIs of some larger SaaS companies are "offline" -- e.g. returning 503 --, so these things do happen.)"]]></description>
<dc:subject>webhooks api apis design</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:9658b3061911/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:webhooks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:apis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:design"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://docs.oocharts.com/">
    <title>OOcharts JS by OOcharts</title>
    <dc:date>2013-08-07T04:38:35+00:00</dc:date>
    <link>http://docs.oocharts.com/</link>
    <dc:creator>earth2marsh</dc:creator><description><![CDATA[OOcharts is an awesome little project that makes it easy to embed and share Google Analytics data through charts. It was started in the Summer of 2012 by Tin Bin and continues to grow. ]]></description>
<dc:subject>analytics api Google wrapper dashboard visualizations service</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:9dd20dbc8a7b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:analytics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:Google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:wrapper"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:dashboard"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:visualizations"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:service"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://mathieu.fenniak.net/the-api-checklist/">
    <title>The Web API Checklist — 43 Things To Think About When Designing, Testing, and Releasing your API | Mathieu Fenniak</title>
    <dc:date>2013-07-23T20:37:59+00:00</dc:date>
    <link>https://mathieu.fenniak.net/the-api-checklist/</link>
    <dc:creator>earth2marsh</dc:creator><description><![CDATA[""]]></description>
<dc:subject>checklist restful api design apis rest</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:bc71f06b338e/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:checklist"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:restful"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:apis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:rest"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/trentm/restdown">
    <title>trentm/restdown</title>
    <dc:date>2013-07-23T02:01:16+00:00</dc:date>
    <link>https://github.com/trentm/restdown</link>
    <dc:creator>earth2marsh</dc:creator><description><![CDATA[""]]></description>
<dc:subject>markdown rest api apis documentation descriptions</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:b06981f23075/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:markdown"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:rest"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:apis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:documentation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:descriptions"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://friends.diy.org/">
    <title>DIY Developers</title>
    <dc:date>2013-07-23T02:00:01+00:00</dc:date>
    <link>http://friends.diy.org/</link>
    <dc:creator>earth2marsh</dc:creator><description><![CDATA[another good example of interactive docs]]></description>
<dc:subject>rest api apis documentation generated</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:e908cf95a218/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:rest"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:apis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:documentation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:generated"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://tools.ietf.org/html/draft-nottingham-http-problem-03">
    <title>draft-nottingham-http-problem-03 - Problem Details for HTTP APIs</title>
    <dc:date>2013-07-09T03:03:52+00:00</dc:date>
    <link>https://tools.ietf.org/html/draft-nottingham-http-problem-03</link>
    <dc:creator>earth2marsh</dc:creator><dc:subject>url APIs design api urls errors</dc:subject>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:c4540de04dc1/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:url"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:APIs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:urls"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:errors"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.garethshapiro.com/item/simple-objective-c-api-service">
    <title>Gareth Shapiro | London Based Freelance Web &amp; Mobile Consultant, Developer &amp; Trainer » Simple Objective-C API service</title>
    <dc:date>2013-05-24T21:36:35+00:00</dc:date>
    <link>http://www.garethshapiro.com/item/simple-objective-c-api-service</link>
    <dc:creator>earth2marsh</dc:creator><description><![CDATA["I am sure many Objective-C developers, iOS or OSX, have been in the situation where the backend API needed for the project they are working on has not been developed by the time they need to start writing the code that will access it. In organisations such as creative agencies, startups and software companies it is not always possible to synchronise resources to perfectly suit all the current projects' timelines but with a mixture of creativity and technology, conveniently wrapped up in a utility called SimpleObjectiveCAPIService, this simple bottle neck can be negotiated. "]]></description>
<dc:subject>mocking apis api ios objectivec</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:319f3523a7df/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:mocking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:apis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:ios"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:objectivec"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www4.in.tum.de/~blanchet/api-design.pdf">
    <title>The Little Manual of API Design</title>
    <dc:date>2013-05-21T16:12:54+00:00</dc:date>
    <link>http://www4.in.tum.de/~blanchet/api-design.pdf</link>
    <dc:creator>earth2marsh</dc:creator><description><![CDATA[""]]></description>
<dc:subject>pdf api apis design development</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:3baefb83b541/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:pdf"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:apis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:development"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://apiaxle.com/">
    <title>ApiAxle - Free, on-premise, open API management</title>
    <dc:date>2013-05-18T03:33:44+00:00</dc:date>
    <link>http://apiaxle.com/</link>
    <dc:creator>earth2marsh</dc:creator><description><![CDATA[""]]></description>
<dc:subject>api proxy</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:12e01cdf59ee/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:proxy"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://dev.w3.org/2009/dap/ReSpec.js/documentation.html#webidl-support">
    <title>ReSpec.js — W3C Specification Writing Tool</title>
    <dc:date>2013-05-15T14:54:13+00:00</dc:date>
    <link>http://dev.w3.org/2009/dap/ReSpec.js/documentation.html#webidl-support</link>
    <dc:creator>earth2marsh</dc:creator><dc:subject>api descriptions ietf tools</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:5614c254f512/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:descriptions"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:ietf"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:tools"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://mathieu.fenniak.net/stop-designing-fragile-web-apis/">
    <title>Stop Designing Fragile Web APIs | Mathieu Fenniak</title>
    <dc:date>2013-04-25T16:16:07+00:00</dc:date>
    <link>https://mathieu.fenniak.net/stop-designing-fragile-web-apis/</link>
    <dc:creator>earth2marsh</dc:creator><description><![CDATA["What’s the difference between these URLs?

http://api.fbi.gov/wanted?
  order_by=notoriety,desc&
  limit=10&
  page=1&
  fields=name,aka,known_associates,
  reward,description,last_seen
This is a URL for the FBI most wanted list. The API contains many features: you can order by arbitrary fields, ascending or descending; you can specify the result count; you can query page-by-page; and you can specify details to retrieve.

Versus…

http://api.fbi.gov/wanted/most
This is a URL for the FBI most wanted list.

These URLs have the same goal, but they vary in how they accomplish it. The first is a programmer’s design. Programmers know what they can provide, and they give you every feature they can. The design does not describe the intent of the user, but instead defines details about the request. The second URL is very specific about its intent to deliver “The FBI Most Wanted List”, and vague about the details; this is an intent-driven design."]]></description>
<dc:subject>ifttt via:pocket api apis design fragility intent</dc:subject>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:ce0800bcd234/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:ifttt"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:via:pocket"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:apis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:fragility"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:intent"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://api.pinboard.in/v1/posts/all">
    <title>Pinboard Backup command using the API</title>
    <dc:date>2013-03-22T23:37:02+00:00</dc:date>
    <link>https://api.pinboard.in/v1/posts/all</link>
    <dc:creator>earth2marsh</dc:creator><description><![CDATA[wget -O- -q https://myuser:mypass@api.pinboard.in/v1/posts/all | gzip -9 > /backupdir/pinboard-myuser.json.gz]]></description>
<dc:subject>pinboard backup api</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:81c4207608ad/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:pinboard"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:backup"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.balancedpayments.com/">
    <title>Balanced - Payments processing, escrow, and payouts in one simple API</title>
    <dc:date>2013-03-01T17:12:26+00:00</dc:date>
    <link>https://www.balancedpayments.com/</link>
    <dc:creator>earth2marsh</dc:creator><description><![CDATA[from Pinboard Network RSS Improver http://pipes.yahoo.com/pipes/pipe.info?_id=b22b9c9acee5906aab7e8a7645a247a9

Seems to be a Stripe competitor?]]></description>
<dc:subject>iftttGR apis api payment processing</dc:subject>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:c77dc9b07d3a/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:iftttGR"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:apis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:payment"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:processing"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/linkedin/rest.li/wiki/Rest.li-.restspec.json-Format">
    <title>Rest.li .restspec.json Format · linkedin/rest.li Wiki</title>
    <dc:date>2013-02-20T17:38:53+00:00</dc:date>
    <link>https://github.com/linkedin/rest.li/wiki/Rest.li-.restspec.json-Format</link>
    <dc:creator>earth2marsh</dc:creator><description><![CDATA[LinkedIn's Interface Description Language]]></description>
<dc:subject>linkedin descriptions format apis api schema schemas opensource</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:df5e7c683284/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:linkedin"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:descriptions"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:format"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:apis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:schema"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:schemas"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:opensource"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://developers.facebook.com/roadmap/change-policy/">
    <title>Breaking Change Policy - Facebook Developers</title>
    <dc:date>2013-02-04T07:18:25+00:00</dc:date>
    <link>https://developers.facebook.com/roadmap/change-policy/</link>
    <dc:creator>earth2marsh</dc:creator><description><![CDATA["We are committed to a 90-day breaking change policy. This means Platform changes that would require a code change from developers (security and privacy changes excluded) will be announced at least 90 days before the change goes into effect.

Starting with the April 2013 breaking change, we will bundle all breaking changes (security and privacy changes excluded) into quarterly updates.

To clarify what's covered by this policy, here are some examples of changes we might make.

Change/removal of major functionality
We may decide to change or remove existing major functionality, such as removing FBML, the REST API, an SDK or requiring SSL. These types of changes will always be announced 90 days prior to the change going into full effect.

Backwards compatibility
We will continue to enhance our existing APIs and reserve the right to add new parameters, return fields, etc. (such as adding new Page functionality or the ability to get the list of people a user is subscribed to). These changes shouldn't break any existing apps. Please ensure your apps properly handle these scenarios.

Facebook product changes
Facebook products will continue to evolve and we'll communicate these changes when they launch, but not always beforehand. For example, we might improve the Login Dialog or add/move discovery points. We'll strive to minimize disruption.

Privacy and security-related changes
We are committed to fixing privacy and security-related vulnerabilities as fast as possible even if this might mean introducing a breaking change. In these situations, which we strive to avoid, we will work with developers to quickly provide workarounds so they can fix their apps as soon as possible. However, due to the nature of these issues, timeliness is key and there's no way to pre-announce the changes.

To stay up to date on all upcoming changes, be sure to subscribe to our Developer Blog where all breaking changes will be announced. You can also check out the Developer Roadmap to see a full list of all upcoming breaking changes. To test out breaking changes in advance, you can use Migrations. If you ever notice a breaking change that falls out of our 90-day commitment, please file a bug and tag it with the "breaking change" tag to help keep us true to our commitment."]]></description>
<dc:subject>facebook api apis breaking changes deprecation policy community management</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:earth2marsh/b:a3a237cd9d3f/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:facebook"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:apis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:breaking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:changes"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:deprecation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:policy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:community"/>
	<rdf:li rdf:resource="https://pinboard.in/u:earth2marsh/t:management"/>
</rdf:Bag></taxo:topics>
</item>
</rdf:RDF>