As the first comment in the article mentions, this guy just replaced REST with REST. Nothing revolutionary. I thought he was going to talk about some rpc mechanism or something.
Problems with RESTful APIs (2015)
81–90 of 224 posts
Re: Problems with RESTful APIs (2015)
#82Earlier quoted context omitted.
> I think what bothers me most about REST is that the endpoint is not sufficient to get started. The schema is never known. If you are actually doing REST, the interpretation of a resource representation is fully specified by the media-type (insofar as if there is additional schema, etc., information necessary, how to find that given the actual representation is also defined by the media type.) Obviously, this is not…
You can sprinkle links/rel and use custom/vnd mime types (and include links to the correct json or xml schema) and then a developer can figure out how an API works just from an endpoint, yes .. but that's not what this person is saying. The thing about SOAP is that it is very concrete and a standard. Yes you get implementation glitches/bugs here and there, but for the most part, you have a standard definition for an…
Swagger is a decent middle ground. There's a lot of warts, but it's serviceable and fairly prevalent with implementations in a variety of languages. Mainly I like to use the yaml version to quickly communicate rest api's. I've also recently started appreciating JSON Schema more recently for this reason. It's lighter weight than xml schemas. Inclusion of regex based field validation is pretty handy.
Re: Problems with RESTful APIs (2015)
#83As everyone else points out, GET and POST are really all thats implemented in anything else other then a catelogging system.
So if we concede that people using these 2 operations are not implementing REST, what are they implementing? Well i would argue, CQRS.
GET = Query, POST = Command
Then our REST api becomes super simple and consistant across implementations.
/api/run POST UpdateModelCommand { } /api/run GET ListModelQuery { }
Re: Problems with RESTful APIs (2015)
#84In 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…
Came here looking for a comment like this. If you're not discussing HATEOAS at all, you will be losing out on many of the benefits that REST provides.
Re: Problems with RESTful APIs (2015)
#85I'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…
Http-rpc is. People call it rest nowadays even when it isn't nor understand the state tranfer part of rest. Not saying it's your case specifically but I'we seen exactly zero http-rpc API implementing rest but a shitton people claiming their json-rpc interface was.
Re: Problems with RESTful APIs (2015)
#86fairly idiotic.
Re: Problems with RESTful APIs (2015)
#87Sorry for the controversial question, and I probably raised my eyebrow if I saw a candidate choose XML over JSON when taking on a recent project... but really, why JSON? No comments, no multiline, no schema. I understand that XML is bad because ____ (not cool, verbose, old school, only enterprises use it?) I am not a huge YAML fan but it seems this is the only human readable form of JSON. The lack of self describing…
JSON, as the name suggests, is easily and natively consumable by JavaScript, the only language to run natively in web browsers.
And everyone uses a web browser.
Ergo, if you develop an HTTP API, you should do it with JSON so it can work easily in web browsers.
Re: Problems with RESTful APIs (2015)
#88I'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…
> I've been trying hard for years to find a reason to bother with PUT, but so far I've found it not worth the effort. And right there, at your final sentence, you basically described why REST has more or less failed. GET and POST are useless for implementing a complete application protocol. You'd basically overload these http verbs to the point where you would implement your own protocol. And that's what most people…
Rest is a well defined semantic everybody bastardized because they find shameful to say they use json-rpc on the resume or elsewhere. There's a difference there.
Re: Problems with RESTful APIs (2015)
#89In 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…
Came here looking for a comment like this. If you're not discussing HATEOAS at all, you will be losing out on many of the benefits that REST provides.
It's the 'central dogma' of RESTful services.
Re: Problems with RESTful APIs (2015)
#90Like other posters have said, the author appears to be pointing out shortcomings with HTTP, not REST. 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: https://en.wikipedia.org/wiki/Representational_state_transfe... . Anything that meets these constraints is considered "REST". Most of the constraints sound like common…
> 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)?