#rest

127 bookmarks tagged with #rest · RSS Feed · ← All Tags

Most RESTful APIs aren’t really RESTful | Florian Krämer

https://florian-kraemer.net//software-architecture/2025/07/07/Most-RESTful-APIs-are-not-really-RESTful.html
Fielding’s rules emphasize that a truly RESTful API should embrace hypermedia (HATEOAS) as the central mechanism for interaction, not just use HTTP as a transport. REST is protocol-independent at its core; HTTP is simply a convenient way of using it. Clients should discover and navigate resources dynamically through links and standardized relations embedded in representations — not rely on hardcoded URI structures, types, or external documentation. This makes REST systems loosely coupled, evolvable, and aligned with how the web itself operates: through representation, discovery, and transitions. REST isn’t about exposing your internal object model over HTTP — it’s about building distributed systems that behave like the web.

Combining HTML Hypermedia APIs and Adaptive Web Design – Jayway

http://www.jayway.com/2012/08/01/combining-html-hypermedia-apis-and-adaptive-web-design/
HTML is the lowest common denominator in a world where the number of devices are steadily growing. In such a world, our API should be hypermedia driven and we should consider choosing HTML as the media type for our APIs. If we choose this, we can enhance the API with CSS and JavaScript, making the API human-friendly as well. Further, we can use Adaptive Web Design to make the best possible experience for all types of browsers and devices. This kind of solution has some risks and technical issues related to it though. And it is not a silver bullet.

A Hypermedia API Reading List - Literate Programming

http://blog.steveklabnik.com/posts/2012-02-27-hypermedia-api-reading-list
Originally, this post was titled "A RESTful Reading List," but please note that REST is over. Hypermedia API is the new nomenclature. I've been doing an intense amount of research on Hypermedia APIs over the last few months, and while I didn't save every resource I found, I've made a list here of the most important.

Haters gonna HATEOAS — Timeless

http://timelessrepo.com/haters-gonna-hateoas
Now, when I said ‘nobody’ does this, what I meant was ‘for APIs.’ This is exactly how the Web works. Think about it. You start off on the homepage. That’s the only URL you have to know. From there, a bunch of links point you towards each state that you can reach from there. People would consider it ludicrous if they had to remember a dozen URLs to navigate a website, so why do we expect the consumers of our APIs to do so as well?

APIs are a Pain

http://www.subbu.org/blog/2011/11/apis-are-a-pain
I would love to see every API to be RESTful, consistent, hypertext driven, and more importantly, interoperable. The reality is that getting consistent APIs is hard – particularly those that are done by distributed teams. For the record – I vehemently hate SOAP APIs and the SOAP mindset. I dislike RPC-style operation names tunneled over HTTP. I frown and cringe whenever I see unnecessary custom headers and complicated formats. I wish POST+XML goes away. I wish every API gets rewritten to the modern understanding of HTTP and REST, serving JSON. But I would rather spend my time enabling interoperability than preaching for consistency.

I finally get REST. Wow. - The Tripping Point - Pluralsight Blogs

http://www.pluralsight.com/community/blogs/tewald/archive/2007/04/26/46984.aspx
"The essence of REST is to make the states of the protocol explicit and addressible by URIs. The current state of the protocol state machine is represented by the URI you just operated on and the state representation you retrieved. You change state by operating on the URI of the state you're moving to, making that your new state. A state's representation includes the links (arcs in the graph) to the other states that you can move to from the current state. This is exactly how browser based apps work, and there is no reason that your app's protocol can't work that way too."

PUT vs POST in RESTful Web Service « vincenthome’s Tech Clips

http://vincenthomedev.wordpress.com/2008/12/18/put-vs-post-in-restful-web-service
"This explains when to use POST or PUT for creating new resources. The answer ultimately lies in who is responsible for determining the new resource’s URI. If the client is in charge, the client can use PUT to the new URI (like we did for user accounts) and the service can return a response code of 201 (“Created”). However, if the service is in charge of generating the new URI, the client should POST the new resource to a factory URI like we’ve done for bookmarks. Then, the service can return a response code of 201 (“Created”) along with the URI of the new resource in the response “Location” header."

REST APIs must be hypertext-driven » Untangled

http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
"What needs to be done to make the REST architectural style clear on the notion that hypertext is a constraint? In other words, if the engine of application state (and hence the API) is not being driven by hypertext, then it cannot be RESTful and cannot be a REST API. Period. Is there some broken manual somewhere that needs to be fixed?"

ongoing · Learning REST

http://www.tbray.org/ongoing/When/200x/2008/10/01/Learning-REST
"I was talking to a colleague who has to become savvy in a hurry about modern Web applications and he asked “How do I learn about REST?” Good question. I thought of a couple of suggestions, then asked Twitter and got some more. Here they are."

Dare Obasanjo aka Carnage4Life - Explaining REST to Damien Katz

http://www.25hoursaday.com/weblog/2008/08/17/ExplainingRESTToDamienKatz.aspx
"At this point, the benefits of building RESTful services for the Web should be self evident. The Web has a particular architecture and it makes sense that if you are deploying a service or API on the Web then it should take advantage of this architecture instead of fighting against it. There are millions of deployed clients, servers and intermediaries that support REST and it makes sense to be compatible with their expectations. "

Joe Gregorio | BitWorking | The role of REST in Cloud Computing

http://bitworking.org/news/354/the-role-of-REST-in-cloud-computing
"I am in no way saying that AtomPub is the solution. What I am pointing out is that if you want federation then you need to design your protocols and APIs RESTfully. In this example it is hypertext, link following, in the AtomPub spec that allows these two separate services to be linked together."

joshua's blog: beyond rest

http://joshua.schachter.org/2008/07/beyond-rest.html
"In some ways this is slightly more elegant than the XMPP solution as neither side has to maintain a dedicated long-running process. ... There are a number of people on inexpensive service providers who have at best web scripting hosting and not much else

Blinksale | Blinksale API

http://www.blinksale.com/api
"The Blinksale Application Programming Interface is simply another way to access your Blinksale data—one that makes it easy for third-party and custom tools to programatically access and interact with the service. The API follows the REST style, and this guide should provide everything you need to implement software that works with Blinksale."

XML.com: Introducing OpenSearch

http://www.xml.com/pub/a/2007/07/20/introducing-opensearch.html?ATT=Introducing+OpenSearch&CMP=OTC-TY3388567169
"You go to your favorite Web 2.0 search engine and set up a query like http://web20.example.com/search=john+doe&ouptut=atom and search for "john doe," but rather than getting back results as the usual HTML web page, you get it back in Atom format."

URI Templates

http://www.ietf.org/internet-drafts/draft-gregorio-uritemplate-00.txt
"URI Templates are strings that can be transformed into URIs after embedded variables are substituted. This document defines the structure and syntax of URI Templates."

"High" REST [@lesscode.org]

http://lesscode.org/2006/03/19/high-rest
"GET/POST/PUT/DELETE advocates who claim they are pointing out the obvious are actually making a religious argument, and that poor thesis is playing the role of C-3P0 in the Ewok village. It's unproven technology, and it should be viewed with healthy skep