A resource designed to enable doing a partial updates to another resource.
A resource designed to provide a logical identifier but without being responsible for incurring the costs of transferring the representation.
This type of resource is used to provide a client with the information it needs to be able to access other resources. This removes the need for a client to hardcode resource URLs which include information such as the protocol scheme, host, path and query string.
A progress resource is usually a temporary resource that is created automatically by the server to provide status on some long running process that has been initiated by a client. It is used to provide feedback to an end user and point to the results of an operation once it has completed.
A builder resource is much like a factory resource in that it is used to create another resource, however, it is a transient resource that enables idempotent creation and allows the client to specify values that cannot change over the lifetime of the created resource.
I've spent a large part of the last two years playing the role of a technical marketeer. Call it developer advocate, API Evangelist, or my favourite title, API Concierge, my role was to engage with developers and help them, in any way I could, to build better HTTP APIs. I have really enjoyed the experience and had the opportunity to meet many great people. However, the more you hear yourself talk about what people should do, the more you are reminded that you aren't actually doing the stuff you are talking about any more. The time has come for me to stop just talking about building production systems and start doing it again.
Although I know my HTTP and Web API pretty well, becoming an API Evangelist on the Azure API Management team means also needing to know the nitty gritty of the Azure API Management product too. In my learning process I have discovered a wealth of useful information, but it is scattered around a little. Some is on the Azure documentation site, some on Channel 9, some on YouTube and some awesome content from our Microsoft MVPs. This post is my attempt to gather it together to make it a bit easier to find.
In my last post I discussed what I perceive to be a misuse of the term self-description. I made the claim that one of the negative side-effects of this misuse is the development of more API metadata description languages. I believe this is a path we have travelled before and it is a dead end.
The recording for episode #3 is now available on Crowdcast and YouTube. In this episode we cover issues like API description languages, security weaknesses in HTTP APIs and the illusive HTTP status code 410 Gone.