I believe I understand what REST is and what Agile is. Our company has some APIs that we maintained, usually we only needed to tweak some requests or responses to fit new requirements. Recently, we had a need to create new set of API.
The design of the new API was driven by how the client would interact with the server. Because the interactions are simple and had been agreed between the client and server teams, the API will only support a couple of requests, i.e. PUT & GET requests for purchase and a POST request for cancellation.
It then become obvious that the API is not REST at all (although both teams agreed to make REST API). For example, there's no link relation anywhere to drive the client and there not even an initial URI that can drive clients.
One example that prevented to implement something closer to REST is that because the client already how to interact, then adding link relations to responses would add no value to the user, i.e. not agile.
REST is software design on the scale of decades: every detail is intended to promote software longevity and independent evolution. Many of the constraints are directly opposed to short-term efficiency. Unfortunately, people are fairly good at short-term design, and usually awful at long-term design. Most don’t think they need to design past the current release.
That's a quote from Fielding, which I also find hard to reconcile with agile. We don't expect our API to still be used after a decade. If the API passed the tests, we'll release it and that should be the end of it, exactly what he said.
So, the question is, is it true that we can't make REST API in agile development and that you have to choose between REST or agile? Any example of real REST API that was done with agile process?
By REST here I mean an API where you can use it just how people browse the web, without relying on documentation pages.
To clarify why this is different from doing architectural design in with Agile approach, there was no real design work other than to agree that it would be a REST API. We pretty much went straight to implement the elements that's really needed and the end result (which met the user requirements) is not really a REST API.