201–210 of 224 posts
I'm not saying there aren't answers to these questions, but doing any of these things in REST is not straight-forward.
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…
No.. So any creation or update can be a POST. If your operation is idempotent, then you can make it a PUT. If you take the subset of POSTS that are idempotent in your application, this is what could be made a PUT.
So a set operation foobar=50, would could be a POST, but since its idempotent, it could also be a PUT.
A increment operations foobar++, would have to be a POST, but could not be a PUT since it is not idempotent.
Earlier quoted context omitted.
…and having implemented HATEOAS in a service (via json+hal), we’re moving far away (GraphQL) because of versioning, payload weight, and lack of flexibility. I’m sure there are things we could have done better, but the reality is that our clients need things that work differently than a “proper” REST/HATEOAS service. We tried. We failed (insomuch as delivering a working service is failure, but we know it can’t grow th…
Like any other architectural model, REST is good for some things, not for others. Versioning and payload weight seem like weird problems to have, though. Seems like JSON might have been a poor encoding for your use case. By the way, do you have a link to that work by fishworks?
I did a quick look for the fishworks commentary, but I can’t find the discussion (this was from before the Borgacle consumption of Sun) about how much of a mismatch it was to implement VM controls through a REST interface. Is it legit to POST /vm/:id/restart or should it be a PATCH /vm/:id with a payload of { "action": "restart" }? Or…
Many advocates of a particular programming style (OO, REST, TDD are some of the more vocal, but FP advocates are right in there, too) seem to adopt the view that it is appropriate for everything. There’s definitely some impedance mismatch if you try to be REST “pure“ between that and the real world, the same as there will be if you go “pure“ for OO or FP for the same sort of things, but there will be different impedance mismatches.
I really tried with HATEOAS, because it makes sense, but the overhead has turned out to outweigh the costs for everything we’ve needed.
Earlier quoted context omitted.
> Roy Fielding made it fairly clear that REST is not strictly associated with HTTP. REST, as an architectural style, is defined by a set of constraints: Out of curiosity, do you know of any examples of RESTful APIs that use a protocol other than HTTP (say like IMAP or NNTP)?
He isn't going to provide you an example because there is none meaning full in production. REST uses HTTP because it makes no sense to use it with anything else. REST only makes sense with HTTP. With another socket protocol, there is no need to bother with headers and co.
Earlier quoted context omitted.
An insert cannot be idempotent by the very definition of the operation.
Requesting an insert can be idempotent. Each non-idempotent operation is tagged with a unique identifier, if the server doesn't have inserted data tagged under that identifier, then it performs the insert, if it does, then it returns the usual success code as if it had just performed the insert. This unique identifier is simply a durable representation of a future which I described above.
Earlier quoted context omitted.
Because applications have state. In fact, the vast majority of reads in any applications are stateful (the database backing your app is also state, you know; I'm not talking just about session state here). By "pure" here I mean that we're talking about a pure function of its inputs.
Why do you need to distinguish between those? In fact, if the function is pure, why not run it on the client?
Why distinguish? Because if you know that the results are not affected by server state, they can be cached much more aggressively.
I'm going to have to call bullshit on that one. REST is one of the more successful strategies we've come up with for connecting systems, this is just another case of letting perfect stand in the way of good enough. Using GET for non-destructive operations and POST for updates and deletes is a nice, portable compromise. I've been trying hard for years to find a reason to bother with PUT, but so far I've found it not w…
Earlier quoted context omitted.
To be clear, I think we're talking about REST without HATEOAS. And I think this is better, imo, as you can write your client knowing the protocol. I've not come across a convincing description of why HATEOAS is a good thing at all. And I say this as someone who thinks capability based design is a good thing. The reasons I have against it are that 1. I think it complicates the client because it needs to discover the a…
HATEOAS is a great concept, but we can only really take advantage of it if and when we move from this troglodyte era of APIs. The fact that we still consider normal to write new "client libraries" for each new service created is just absurd. Imagine if we had to write a new browser plugin for each new site we published - that's at the level we're at on APIs! To be more specific, HATEOAS is an essential component to c…
Still happens all the time in mobile world. Not as obvious in Desktop word because the site is the app, you just download it each time anew instead of once. But there are Chrome plugins for many sites - Chrome web store has a lot of them. Most of the sites can work fine without them, nevertheless they exist.
Earlier quoted context omitted.
To be fair, the verbs can feel a little weird. GET is easy. HEAD is easy. DELETE is easy. PATCH is easy, especially when you use one of the two more useful standards (RFC 7386: JSON Merge Patch, or RFC 6902: JSON Patch). PUT is not much use for large resources (like those typically found in business systems) since it requires you to provide every field, but usually you would want the back end to assign at the last th…
When you say you want the server to assign the identifier and additional fields, then I guess this would be considered read-only metadata against the resource. I don't recall seeing anything stating that in my RESTful travels.