141–150 of 224 posts
Earlier quoted context omitted.
>That POST is actually meant for updates and PUT is meant for new entities This is definitely the other way around.
http://stackoverflow.com/questions/630453/put-vs-post-in-res...
When I was given the task of defining how our multi-robot server would interface with our user interfaces, I eventually settled on REST. Most of what I knew about REST had been obtained that week. I implemented something pretty vanilla with Django and it all felt pretty elegant. I didn't have to worry about defining a protocol, there was pretty much already one for me: - GET, PUT, POST, DELETE (I learned there were o…
>That POST is actually meant for updates and PUT is meant for new entities This is definitely the other way around.
POST is meant for anything and everything, absolutely including updates. PUT is meant for writing-or-overwriting a complete or partial resource, at a URI that is the Request URI. In practice, for most applications, this makes PUT impractical for new entities (because the requester cannot know the correct URI for the new resource), but in some applications it can make sense, and either way there's more to it than you assert.
Earlier quoted context omitted.
http://stackoverflow.com/questions/630453/put-vs-post-in-res...
Like usual, the accepted answer is somewhat correct but not quite the best. Idempotence is the thing from which correct understanding of PUT and POST is derived.
The fact that the request-URI is to be the new home of the entity being PUT is the thing from which correct understanding of PUT is derived. Idempotence is a trivial consequence of that (so not necessary in its own right), and is not sufficient. Read the RFCs.
Earlier quoted context omitted.
> You can install browser extensions to make it even more readable. Most browsers can display XML readably by default. > Schema can come from a well written specification. That doesn't replace a schema though. > No, as said before, it's easy to write / read / generate / parse. No awkward DOM style management if you want to parse out a value. "DOM-style management" of XML documents which can be replaced by JSON is equ…
> Most browsers can display XML readably by default. True, but a JSON string is already more readable than XML. If you open your devtools it's inspectable by default: http://imgur.com/a/eW0Rv > that's not quite the case for languages like C++ or Haskell. So handling XML in those languages are easier? BTW if your server / services feel more native with XML serialization / parsing to native data structures use that. Pi…
That also works for XML documents: http://i.imgur.com/NmcWdaO.png
> So handling XML in those languages are easier?
Both are "crap" since they're dynamic information which has to be brought into a statically typed world. However depending on the schema it might be possible to automatically generate the binding and hide the dynamic resolution.
> BTW if your server / services feel more native with XML serialization / parsing to native data structures use that. Picking JSON just because everybody else does it is not a good idea.
> However if you make a public web API consumed mostly by browsers (JS), then yeah, pick JSON and REST.
Agreed.
Earlier quoted context omitted.
The point of having something like PUT (that is known to be imdepotent) is that it can be retried by any of the layers in the stack, instead of having a full roundtrip back to the client on every retry. And it's not always safe to retry POSTs. If POST is an insert, for example, retrying it would produce two inserts. And this can have interesting consequences when processing responses. Suppose that you have sent a POS…
> And it's not always safe to retry POSTs. If POST is an insert, for example, retrying it would produce two inserts. [...] Suppose that you have sent a POST request, but before you could read the response, connection dropped. My previous post already covered idempotent POSTs via futures. The fact is, only the application can decide whether a POST is safe to retry arbitrarily or must be made safe by binding to a futur…
Earlier quoted context omitted.
What we really need is a set of verbs that allow to reliably distinguish between these three types of operations: 1. Pure read. 2. Impure (stateful) read. 3. Idempotent write. 4. Any other write. There's no particular reason to separate inserts, updates, deletes etc as part of the protocol - they're all just different kinds of writes, and middleware doesn't derive any benefit from being able to distinguish them. Thus…
It's not worth making the distinction between idempotent and non-idempotent writes given the possibility of network partitions. Every write must be made idempotent because all you can do is retry in this case. PUT is merely an optimization on idempotent POST requests, one that will become progressively rarer as HTTPS continues to spread. POST requests can be made idempotent by binding the result of processing that re…
Earlier quoted context omitted.
What we really need is a set of verbs that allow to reliably distinguish between these three types of operations: 1. Pure read. 2. Impure (stateful) read. 3. Idempotent write. 4. Any other write. There's no particular reason to separate inserts, updates, deletes etc as part of the protocol - they're all just different kinds of writes, and middleware doesn't derive any benefit from being able to distinguish them. Thus…
Why oh why oh why do you want a stateful read? That will be the beginning of the end for your architecture.
By "pure" here I mean that we're talking about a pure function of its inputs.
In my opinion, you can't really understand REST until you understand HATEOAS - the two concepts work together and REST (and the restrictions it imposes) isn't really very meaningful without HATEOAS. Twilio Conference 2011: Steve Klabnik, Everything You Know About REST Is Wrong: http://vimeo.com/30764565 REST APIs must be hypertext-driven: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte... Hypermedia APIs…
I might be unlucky but I've personaly never encountered a single REST API that implements HATEOAS (among many third party APIs I've integrated into softwares I've been working on on). If almost nobody who implements a REST API has HATEOAS in mind, doesn't it mean that REST is de facto independent from HATEOAS, no matter what the initial theoretician said about what REST should contain ? In other words, if REST mean s…
Accepting the redefinition of terms merely because they are popularly misunderstood is literally putting the inmates in charge of the asylum. wink
Earlier quoted context omitted.
What we really need is a set of verbs that allow to reliably distinguish between these three types of operations: 1. Pure read. 2. Impure (stateful) read. 3. Idempotent write. 4. Any other write. There's no particular reason to separate inserts, updates, deletes etc as part of the protocol - they're all just different kinds of writes, and middleware doesn't derive any benefit from being able to distinguish them. Thus…
PATCH verb? I've seen it in the wild
Earlier quoted context omitted.
> If almost nobody who implements a REST API has HATEOAS in mind, doesn't it mean that REST is de facto independent from HATEOAS If it's independent of HATEOAS what is in REST? If it's just doing HTTP, why not call it HTTP?
> If it's independent of HATEOAS what is in REST? Using GET/POST/PUT/DELETE with a defined semantic, the confidence that GET is idempotent, and the proper use of HTTP status codes. Back in 2005, it was really common to have only GET routes even for update of deletion, or worst: to have a single url: http://example.org/action which concentrated all the API surface, different behavior being triggered by the type of the…
That's literally got nothing to do with REST though, that's straight out of RFC 7231 (sections 4 "request methods" and 6 "response status codes") and the IANA HTTP Method Registry.
