So for reasons unclear you tried to replace a working system with a design pattern you didn’t really understand, and you were disappointed with the results? What were you hoping to get from this madness?
Honestly, REST is a great idea. Yes, people get religious about HTTP verbs and URL structures. But you don’t need to. Prioritise clarity to humans above everything else, and you’ll be fine for the most part.
> Honestly, REST is a great idea. Yes, people get religious about HTTP verbs and URL structures. But you don’t need to. Prioritise clarity to humans above everything else, and you’ll be fine for the most part.
I've seen this argument before (I've even made this argument before), but I'm becoming increasingly unconvinced by it. Let me explain my thinking:
1. If there's ANYTHING that sets REST apart from a generic HTTP-and-JSON protocol, it's the focus on basing endpoints off the concept of resources and collections, and using HTTP verbs to determine the type action to be performed. (And also, possibly, internal hyperlinks, but nobody seems to actually pay attention to that part.)
2. Depending on your application, somewhere between "some" and "most" of your API traffic doesn't deal things that easily map to resources and collections, doesn't involve actions that easily map to HTTP verbs, or both. One of the most common examples is sessions. When you log in, are you creating a session resource? Is that a sub-resource of the user resources, or an independent collection in its own right? Or are you actually retrieving a session token from the user resource? When you log out, are you actually deleting that session? Or updating the session to remove its authentication?
3. It's easy to say "prioritise clarity to humans", and I totally agree, but in that case, you'd just have a /login and /logout endpoints, you'd do a POST to the former with a valid username/password to login, and a POST to the latter to log out, the end. That's super clear, and super usable, but nothing about that is RESTful. And the same thing comes up over and over again. For every time I find myself doing simple CRUD operations on a collection of concrete resources, there's 10 times I find myself needing to do complicated, ambiguous operations on things which aren't.
4. But if I relax and focus on making a clear, usable API, then almost by definition I have to do so by not being RESTful. It's easy to say that you shouldn't get religious about HTTP verbs and URL structures (and I agree), but since HTTP verbs and URL structures is 100% of what people seem to mean by "REST" in actual practice, then...in what sense is REST a good idea? It's like drinking rum and coke without the rum...and the coke. What's left? Nothing Roy Fielding would recognise, in my view.
I'm happy to entertain the idea that REST is useful when you are doing CRUD operations on simple, concrete resources (updating prices on an online store; posting comments to a blog; whatever). But in my personal experience, most people seem to view REST as the ideal way to handle making an entire API, even the bits that are clearly nothing more than RPCs triggered via HTTP.
> but in that case, you'd just have a /login and /logout endpoints, you'd do a POST to the former with a valid username/password to login, and a POST to the latter to log out, the end. That's super clear, and super usable, but nothing about that is RESTful.
And this is the beauty, compared to SOAP: you can mix-and-match. Make your resources as RESTful as possible (but e.g. omitting passwords/cc numbers), and implement the stuff that's not resources in good ole plain-json way.
For logins there's no other choice anyway, given the tons of different ways: some are email+password, some username+password, some add a tenant parameter to the mix, some add one of the dozens of captcha solutions, some want Oauth, various 2fa schemes, ...
Came to make this exact point. Use a framework to automatically give you a solid, dependable REST api focussed purely on crud operations on your core data model. Anything weirder than that (which I don’t believe will be ten times the volume for the vast majority of use cases), do in the cleanest way possible, even if that means you end up with a non-REST api wrapping a core RESTful one.
REST is a design pattern, and like all design patterns, it can be over-applied.
Bits of your application that have natural nouns - “post”, “credit card”, “product” - fit naturally to endpoints. Log in doesn’t, so don’t try shoehorning it in. If only 80% of your application can be defined as REST level 4 but is clear and easy to use, who cares? And if your domain doesn’t fit well with REST, then don’t use it!
Personally, if I have an object like “product” and want to use some custom verbs, I include them in the “links” section of the product response. My authentication process is in the documentation, with /login and /logout URLs.
My first priority is always to make something usable by humans. I try to do that using REST wherever possible, because usually those goals go together. When they conflict and I can’t resolve them, I choose usability by humans over strict REST principles.
POST represents a non-idempotent operation. The other HTTP verbs (GET, PUT, PATCH etc) are idempotent. The awkwardness surrounding PUT/PATCH stems from the need to ensure that those requests remain idempotent.
Nothing bothers me more than an idempotent request (e.g. a search query) using POST. If you design your API starting with "what should happen if the client makes this request multiple times?", then it becomes much easier to model with HTTP.
HTTP 401 Unauthorized actually means Unauthenticated. 403 Forbidden actually means Unauthorized. Yeah, it is a bit of a mess but the referer header is misspelt so what can you do.
A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request.
A GET request's body has no defined semantics, so your server is firmly in the realm of "nonstandard implementation detail" if you choose to take into account the body in your decision-making.
You manage both dismiss HATEOAS for lack of discoverability and then claim there's no automatically generateable client? If I claimed a WSDL was "discoverability for SOAP", would that make the purpose of HATEOAS clear?
I feel like this is the root of the author's agitation:
"I don’t care. Trees are recognized by their own fruits. What took me a few hours of coding and worked very robustly, with simple RPC, now takes weeks..."
He seems unhappy that REST doesn't work the way his familiar tool (RPC) does. I myself worked with middleware-messages-over-TCP systems for a decade before switching to web apis. I don't have this issue. And I personally don't follow the "holy specification", and REST works just fine for me.
The problem is the assumption of a "simple RPC" protocol... there is no such thing. There are network issues, proxy errors, and two-sided race conditions that complicate any network related code. Network programming is distributed programming, which is not easy. RPC protocols try to mask that difficulty, but more often than not they sweep it under the rug.
RPCs make it easy to get started on a dev machine. making network calls appear like function calls definitely speeds things up when the network is working perfectly, but it papers over the complexities of debugging network issues and complex distributed race conditions, which will inevitably come up later.
Being explicit with network communication has its benefits.
(corollary: for the same reason as above, I don't like lazy evaluation of database queries that exist in many languages. When you hit a database, it should be intentional, you should know about it, and should properly prepare for any necessary network issues, caching, and cursors. Many modern web frameworks gloss over this).
I don't see how those things are really solved with rest, particularly given that people will often be using a wrapper rather than building their URLs manually everywhere.
Definitely not "solved", just made more explicit, kind of like a warning sign in the road. A while ago I worked with an RPC system where the RPC calls looked just like normal function calls... everything worked well, until it didn't.
Anytime a computer program consumes a potentially scarce resource (e.g., network, disk, database, etc), there should be some warning-sign or flag raised to the developer. RPC hides that, whereas REST makes it more explicit. So much of programming is social, and the mechanics of REST, even though theoretically identical to RPC, raise many social flags warning of danger ahead.
Or in other words, there is absolutely no technical justification for using this overly verbose and unmaintainable mess. It's just some vague philosophical thing that has no clear benefits. Like OOP.
I doubt that these qualities are actually achieved. Generally I don't think there have been many (if any) languages where excessive verbosity built in to the language has proven to be a good idea. Think COBOL, Java...
It's worse if not only statements are longer, but you are actually forced to treat similar things in very different ways (like URL resource vs query string vs post parameters). It just increases code complexity without any clear benefit.
I'm not really sure I see the difference. One of the first things done is to wrap all the calls to the webservice in some kind of API (often using a pre-existing library), which puts you back exactly where you were with calling a function which happens to make a web request.
I'm currently developing a product using gRPC-Web as an interface between our client and server-side code. It's very pleasant to work with, especially when using TypeScript on the client side.
Oh, and for those who want to be able to query APIs from the command line without prior knowledge, the following works if you have reflection enabled on your gRPC server:
q3k@anathema ~ $ alias grpc="docker run --rm -it --net=host returnpath/grpc_cli"
q3k@anathema ~ $ grpc ls 127.0.0.1:50051
helloworld.Greeter
grpc.reflection.v1alpha.ServerReflection
q3k@anathema ~ $ grpc ls -l 127.0.0.1:50051 helloworld.Greeter
filename: helloworld.proto
package: helloworld;
service Greeter {
rpc SayHello(helloworld.HelloRequest) returns (helloworld.HelloReply) {}
}
q3k@anathema ~ $ grpc type 127.0.0.1:50051 helloworld.HelloRequest
message HelloRequest {
optional string name = 1[json_name = "name"];
}
q3k@anathema ~ $ grpc call 127.0.0.1:50051 helloworld.Greeter.SayHello 'name: "gRPC World"'
connecting to 127.0.0.1:50051
Rpc succeeded with OK status
Response:
message: "Hello gRPC World"
gPRC is nice... my only two gripes are that it isn't quite as debuggable as JSON, it's often overkill, and because it moves so fast (right now) I've seen updates introduce real errors into the protocol (they are fixed in a few days, but when they occur it's a terror to debug).
I agree 100% with this article. A simple RPC API spec takes minutes to define. 'Rest'ifying takes much longer, there are a million little gotchas, no real standard. Everyone has a different opinion of how it should be done. Data is spread across verbs, urls, query params, headers, and payloads. Everyone thinks everyone else doesn't 'get' REST. If you try to suggest something other than REST in the office you become the subject of a witch hunt. It really is a cargo cult of pointlessness. My co-workers have spent sooo much time trying to get swagger to generate documentation correctly as well as generate client side APIs, and there are countless gotchas we are still dealing with. It really is SOAP 2.0, when a simple JSON/RPC protocol would of done fine. Don't get me started with conflating http server errors with applications errors. And trying to do action like requests with a mindset optimized for CRUD. How much time have we wasted figuring out the 'standard' way to do just a login API call RESTfully. Please comment below how to do it, I love the endless debate of what is REST and what is not.
Well, I'm glad you can put together an RPC api that quick, but the reason REST is so ubiquitous and why arguing against it is going to make you the subject of a witch hunt is because it's so easy to consume. Your API is useless if people don't want to use it.
Are you assuming REST is easier than RPC to develop and/or consume?
After moving to a REST based API there were endless meetings between co-workers of what is and isn't a good REST url. Our clients often come to us with dumb mistakes. Unlike RPC where the parameters go in a single place. With REST the parameters are spread across the verb, url, header, query param, etc..
Yes, I'm assuming REST is easier because of tools like curl, postman and even the major browsers with HTTP GET and great dev tools.
With RPC your consumers probably need to know some coding and even maybe a specific language, a framework or a library.
So yes, for me REST is easier, and I always love to see landing pages like this one - https://freegeoip.net - where the client can test the API in a few seconds by copying an example to its browser address line. This is a simple use case, but I hope you get my meaning.
I don't really understand the debate here regarding tooling. REST, SOAP and RPC are all ways to define/codify the API and the parameters. It all goes over HTTP at the end. So Curl, postman and all other HTTP-enabling tools/libraries can be used.
SOAP even has handy discovery tools that frameworks can consume and construct entire APIs in most popular languages.
It's just that no-one uses SOAP from a browser because XML is a royal PITA to write in JS. I would assume it's because all JS developers are too-busy writing more libraries-for and layers-over JSON.
It's precisely the 'simple' examples which don't address any of the complexities in the original article. read-only properties in a resource being PUT back, for example. You're not having to deal with that with simple read-only services like freegeoip.
I think they were suggesting that it was more difficult to design/develop (as per your example), but easier to consume if designed/developed well, and that this was the proper tradeoff.
Or in the case of SOAP, simply cannot work out how to consume it. In at least one case there was a SOAP service offered and I had a good quality SOAP client library in a popular language and I couldn't work out how to make a single working request.
Not all APIs are public though. You could picking a communication protocol among services within a single technical organization. In that case you can decide to train everybody to use Thrift, for example, if the pros are strong enough.
But like the article mentioned, clients using REST are used to dealing with wrappers written for their language anyway. They'd prefer to not bother with URLs, query strings, and MIME types, and simply consume an API in the language that feels natural for them.
You can argue that REST is easier to debug for developers, but nothing makes XML-RPC or binary protocols inherently _less_ easier to debug. It depends on the platform and library you're using.
I wholeheartedly agree with the article. Well done.
Would be fine, but could include more if you were following a spec like JSON API 1.1. I really don’t have any of the problems you seem to have. But I work in a high level programming language, so maybe it’s that? Either way I find RCPs to get messy when they get bigger. Sometimes it’s the right move, but for web apps I generally prefer REST.
If you're defining an RPC protocol in just a few minutes, you're leaving a ton of stuff out. Anyone that assumes an RPC call will successfully complete or assumes the network is always there, is writing buggy code. An "RPC protocol" makes writing such buggy code easier. A REST protocol makes it slightly harder. In theory, they are almost identical. But in practice, developers equate RPC calls with function calls, which they are definitely not.
There's nothing wrong with wrapping REST APIs, as long as you wrap them in something that makes it clear they are a rest API. There's a huge difference in call foo() and calling http.get("foo").
I've written over 10 applications that use Stripe and every single time, the first thing I did was use Stripe's official library for the languages I work out.
How is it any different in any way than any other async function? You just end up providing an unusually large number of parameters via headers and body, then at some point in the future the request completes with values and/or errors. What separates them?
Classic RPC functions would never be async, since the idea behind RPC is to replace a sync local function with a sync remote function, without having to make any changes to the calling code.
"Async RPC" is a more recent idea, but still gets referred to as "RPC", so the complaints about classic RPC still get raised since the term is overloaded.
The proper REST API should be specified as the set of domain-specific document formats (media-types) and have a custom browser as a client. Turns out, we already have HTML and web-browsers, so there is little point in actually building such APIs. It's always more appropriate to build a website instead. On other hand, what usually called 'REST' is nothing else but RPC where 'procedure call' = 'http method + url'. There is nothing wrong with that (with the exception of the name), but trying to satisfy any REST/HATEOAS constraints on top of RPC foundation seems difficult and pointless.
Don't agree at all. There is a huge difference between calling a function "foo()" that makes an RPC call and the relatively equivalent REST call "http.GET('/foo')". The former feels like a function call, and callers will assume it operates like one. However, in reality the former is not a function, it's making a network call, and it's incredibly unreliable.
In theory, the latter does the same thing, but it's far more explicit, the developer knows it relies on the network and accordingly that it may fail. Developers will be more inclined to plan for errors when the possibility of such errors are more obvious.
What's funny is that most consumers of REST APIs do it through a wrapper that turns it back into a statically typed RPC. REST truly is a useless middleman that no one realizes they just don't need.
I doubt that most consumers of REST APIs are doing anything statically typed. I would guess that the vast majority of REST consumers are written in browser javascript. Server side, I bet at least half are written in a dynamic language.
I don't think the parent here is talking about whether the language is static/dynamic.
The point is that most REST calls are wrapped in a statically 'dispatched' function call.
So in most cases you'd do something like:
let foo = () => http.GET('/foo');
.
.
.
foo() //foo is statically dispatched in the source code here
It seems like "RPC" is being used pretty loosely in this thread. Whether foo in your example is RPC or not depends on its signature, if it attempts to synchronously return the response from the server, then it is RPC, if it just returns a Promise then it isn't.
> There is a huge difference between calling a function "foo()" that makes an RPC call and the relatively equivalent REST call "http.GET('/foo')".
Is it really a useful distinction? Let's rename our 'foo()' to 'dangerously_unreliable_with_unpredictable_latency_foo()'. Is there still a huge difference?
> accordingly that it may fail. Developers will be more inclined to plan for errors when the possibility of such errors are more obvious.
That part of your comment looks suspiciously similar to the usual argument against exception handling to me.
Dangerous and unreliable don't really capture it... how about potentialy_async_call_relying_on_network_that_raises_lots_of_exceptions_foo(), then I'd agree they are pretty similar. However http.get("foo") often says the same thing more succinctly.
And to your second point... yes, all developers should check possible exceptions, just like all children should brush their teeth. However, if you have bad habits and you aren't good all the time, then at lease brush your teeth after eating sweets, and likewise, developers should please check for exceptions around network calls.
Some time ago, another HN user commented a lack of good async support in languages and libraries caused some of the issues with early RPC. With more languages introducing futures and promises as return values or asyncronous functions, don’t you think we might finally have the tools to express that unreliability in a simple function call?
How is that different than any function call that start something in the background? I have used and even written myself simple job code (with threading) that has functions like (simplified):
int start(void (*job)(void*), void (*done)(void*), void* tag);
`job` is called on a separate thread at some point (goes through a job scheduler) and once it is done, `done` is called at the "main" thread (at some synchronization point, usually during the event loop), `tag` is just passed around for context. `start` returns zero on failure.
I don't see RPCs as anything different conceptually (after all the job might also fail). The only issue someone might have is when expecting a synchronous API, but even in non-networked code there are tons of asynchronous APIs.
The main difference is that networks are inherently unreliable. Threaded or multi-processed applications can also be unreliable but for different reasons.
The goal should be to inform the caller of the types of errors that may pop up. Obviously, with network or RPC calls, the caller should handle the case where the network is down. With threaded apps, the potential errors are more subtle, but the caller should definitely be aware that it's not a synchronous call. The function header you proposed is a bit clumsy due to the c semantics, but gets the general point across well enough.
This. REpresentional State Transfer stands in opposition to Remote Procedure Calls - except for a very narrow subset of hypertext/hypermedia applications.
The part I find most interesting about Fielding's thesis[1] is the introduction with architectural overview. He managed to map out modern Web apps perfectly - they can be REST (Web app with db/storage backend, perhaps extended with something like webdav) which is amenable to multilevel caching, smart client;movable data: json api js app, or smart client;movable code: js/Ajax - executing js delivered by server on client (subtly different from a "pure" js/json app (which is similar to an XML/xslt App).
I don't know why the hype of rest lead people to insist on conflating their architectures.
Kind of my point. It's a great dissertation, with some great ideas in it. One of them is REST (Web pages). But the other architectures are well documented in there too - with trade-offs.
Ed: not sure about "time wasted bickering over it". Bickering is always time wasted. Careful analysis of software architecture, patterns, and figuring out what you're actually trying to achieve - is time well spent.
There are fundamental trade-offs between REST and different patterns - depending on where the truth of your data recides, if you need acid or not, and where (what part of) your code executes.
Reading the article I wondered why we even integrate services so deeply with HTTP. The things I care about is the ability to cache at HTTP layer and the option to move endpoints. Which can be added indepentendly of the actual protocol. Moving a service to another protocol than HTTP could be an interesting option.
I think some reasons for still using HTTPS as a starting point are the ease of proxying (load balancing), the support for virtual server names, the fact it's easy to use from a web browser, the built-in encryption with TLS.
Plus, for any given large organizational customer HTTP/HTTPS are allowed through their firewall/other network security apparatus, wheras other ports require a bunch of special exceptions from the security people to use. Said people often refuse to give exceptions no matter how reasonable the request might be, so everybody ends up doing everything on port 80 or 443.
I agree with a lot of the things in your post, but this one in particular has produced the most grief for me:
> Don't get me started with conflating http server errors with applications errors.
I've wasted so much time dealing with 404 errors that were returned by the webserver itself (not the app) because the endpoint I was hitting was wrong or had moved, and vice-versa when I was correctly hitting the app but got a 404 error back from the API and I thought that the endpoint was wrong. And, of course, similar issues for 500 errors and the app itself dying versus the app processing normally and indicating an expected failure response via a 500 error code.
To add to all that badness, a lot of JS libraries in their async API method calls have different error handlers for success and for failure response codes, so you end up having to lump together business logic (for resources not found) and retry/error-handling logic (for the server the not working correctly) into the same failure response callback handler. It'd be much cleaner if all the business logic could be handled in a single callback and all of the failure logic could be handled in another. And, of course, you only even get to this level of badness once you figure that out; you can still waste quite a bit of time before you even realize that your callback is not being called because the JS framework is interpreting the expected 404 your API endpoint is returning for non-existent things in business logic differently than you are.
I still wouldn't go back to SOAP, but I do tend to prefer HTTPS/JSON-based APIs that don't abuse verbs, HTTP error codes, and mixes of URLs/params/headers/payloads. Better to put all of that stuff inside the JSON payload where it will only be handled by the application business logic, rather than mixing it in with all of the HTTP constructs that are used for other things as well.
Agreed I'm very much in favor of JSON body in, JSON response. The URL is just a way to hierarchically organize the endpoints. Just like in binary APIs where public methods are organized in classes and namespaces.
I've always made up my own error codes, which I embed in the 200 response since I end up having to map HTTP codes to what they mean anyway, and many libraries have their own behavior on how to handle various HTTP codes or cannot recognize anything other 200 and other (some LUA engines, for example).
It's often new employees fresh out of college who are the worst. They can be obsessed with doing things 'right', which you can't blame them because they have little experience. The internet tells them REST is right, so anyone who doesn't agree with them is wrong.
> A simple RPC API spec takes minutes to define. 'Rest'ifying takes much longer, there are a million little gotchas, no real standard.
The thing is, RPC is fundamentally broken due to the nature of distributed computing, and REST is not. All the time you have to spend doing things right is … the time necessary to do things right.
And REST really is very simple. The problem is the cargo-cult nature of folks who don't really understand it.
If I had a nickel for every time someone said "don't really understand REST".. often people who both think they understand it say it to each other. It's pretty funny. Guess what, we understand it fine, and we don't like it.
This article expressed a lot of what I’ve been mulling for years.
I must’ve spent hours of my life poring over the Wikipedia HTTP Response Codes page, looking for the most expressive error code for my situation. It’s barmy.
You don't need to. For me, REST can be as simple as: encode the type of request into the URL, request parameters into URL parameters and/or query parameters, request data into a JSON payload. Use GET for read-only operations, and if you're really not particular about it, use POST for everything else. Return 200 for success, 400 for client error and 500 for server error. Transport a more detailed application error code and description in the response body. That's it.
I agree. There are plenty of freedoms built into the REST way that enable you to create more or less detailed responses.
"I don’t care. Trees are recognized by their own fruits.
What took me a few hours of coding and worked very robustly, with simple RPC, now takes weeks..."
Weeks? For a REST API? No, I don't think so. REST gives you the tools to be pragmatic and quick, so use them.
You don't even need that. I don't think there is anything wrong with returning a 200 response with a JSON body that has some 'error' tag built into it. It may not be purely RESTful, but if it's obvious to the developer interacting with the API, who cares.
Not at all. Some languages and libraries don't handle non-200 status codes nicely, they may raise exceptions for each code, or maybe not. For example, Python's basic urllib library makes it easy to get 200 responses but a hassle to get anything else (you need to wrap it in a try/except).
For some APIs, it definitely does make sense to use proper status codes, but for others, it's like fitting square pegs into triangular holes.
well most consumers work better with 400 errors.
(i.e. angular1 or even angular2 where the 4xx error codes will be inside the error clause of the promise/observable)
That means I can't use any kind of generic retry / back off code because I've now got to start dealing with your custom errors, and if you have html versions of the info Google will start demoting you.
You're assuming you want your API to work with a specialized crawler, like Google-bot. If that's important, then sure, design your API so Google-bot can crawl it nicely, but then it's Google designing your API, not you.
I think you missed his primary point. By doing what you describe above, generic client side code to handle retries/backoff etc etc is rendered useless. Your users now have to implement something custom for this (and, if your doing network operations and DONT do this, you likely don't have a very robust system).
> You're assuming you want your API to work with a specialized crawler, like Google-bot.
Not really, I just don't
In general, the key point as about working in a generic way, given that it's so simple.
I don't like the idea of returning a human readable message that says there was an error but a machine readable message that says everything was fine. I have far too many cases of having to deal with human text explaining that a value is missing already in my data.
I disagree, at a minimum, use 200/400/500. Each grouping of error code defines semantics which are implemented by generic clients / servers / middle boxes / monitoring agents etc. These are things out of your control, and often ran by a range of different companies. Debugging these is .. hard.
Yep and when I have to investigate production issues, you're the guy that makes me do slow wildcard queries of the detailed error text instead of just filtering on the (indexed) response code. You push your laziness onto the rest of the world that way.
The worst one I worked with recently would return 200 and only a human readable error message (no status). On top of that the message is sometimes phrased differently. Here is an example from memory: "The field email is not valid." and "You provided an invalid username."
The old spec, https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html, seems to say that 401 can mean either unauthenticated or unauthorized. If you haven't signed in, it means unauthenticated. If you have signed in, then it means unauthorized. Were the status codes written before authenticate and authorize had the narrow meanings of today?
Meanwhile, 403 seems to be reserved for when the server just generally doesn't want to do what you're asking it to do. It may tell you, it may not, it doesn't have to tell you, so there. "Authorization will not help..."
Why is REST so popular? Because it's easy to implement and works for lots of use cases. I'm sorry that you found places it doesn't, but in the real world, having been through that SOAP pain it's being compared to, I'd say there's not even a comparison. Everyone seems to want to find a reason to dislike product/technology/feature X but in this case, X is just better than anything we've had for a 90% adoption case.
What is with medium.com? Why is it so many links to this site are full of hateful hipsteresque opinions looking to sound smarter and more insightful than they actually are?
I think “hipsteresque opinions looking to sound smarter and more insightful than they actually are” is a very good definition for much of Medium’s content.
It may have to do with the platform being used by individuals trying to create a brand of themselves, resulting in a high percentage of sensationalist and controversial posts. Along with the necessity to write on a regular basis.
didn't read all that stuff, busy getting stuff done.
I agree with this. When I end up on a new project and I'm not the lead, and there is a lead who is pedantic regarding how they want their URLs crafted (or wants to implement a complicated query pattern, or introduce an extra layer of objects to satisfy an abstract notion of purity), I'll just go with the flow. Accidental complexity, pattern seeking and cargo-culting are personality traits of many programmers, and I've come to the conclusion that its best to accept this, and get on with the job of actually delivering value.
The problem becomes evident when you return to the results so the flow a year later to change something, and wish you were more mindful when getting things done.
Cargo cults are not good. Finding and adhering to regular patters that logically underlie what you do saves time and mental effort, while also preventing certain classes of errors. (No, these are not GoF design patterns.)
I’m certainly not advocating spaghetti code, balls of mud, or a thoughtless lack of architecture. What I’m specifically referring to is wilful anti-pragmatism that betrays a sort of insecurity...it’s hard to define but easier to recognize.
Finding the balance between pointless over-engineering and rigidity on one hand, and good software design on the other, consistently, is what seems to distinguish great programmers I’ve worked with, from those who are “just” very good.
But, like I said, it often isn’t worth the trouble fighting about these things, even when we see them, and getting on with the job is more important than ensnaring oneself in religious debates on projects.
me: already groaning at the thought of fixing stuff after that one who didn't "read all that stuff," the "left", and thankfully the right was too busy pontificating to do anything so there's no fixing to be done.
I avoid medium posts as much as possible. Everyone is an expert on there with very strong opinions telling me how every technology older than 2 years and not written in javascript is obsolete/dead/not the right way/new <insert a dead technology>.
And what's with the UI on their publications. They take up top 25% of the screen with the branding and navbar and bottom 10% asking me to sign in and both sticks on the screen. Who approved that?
Medium posters borrow clout from medium which makes their post have clout. If you think of medium posters as just bloggers with their own domain or blogspot, you'll see them differently.
Agreed, its a content platform with a where the content fights for attention with the medium.com branding. How many people do you really "never miss a story from"? I generally avoid medium.com for this reason alone.
I'm further puzzled when I see companies using medium for their company blog as well. All I can figure is it must be recommended in some user guide to "growth hacking."
I have another opinion about that. Read as much medium posts aspossible, but keep a critical mind. Medium is nothing but a blog platform, not a science platform, not a news paper. Medium is important, because it makes it easy for everyone to post her/his mindset or agenda. No one has to agree with anyones opinion. But its important to know about those opinions, because it makes it easier to have a dialog.
Isn't it just a content container? I mean, saying "I avoid medium" sounds like saying "I avoid wordpress" or "I avoid blogspot", speaking of content quality and not look&feel. About this one, I'm logged in, so I have to suppose your % (25% and 10%) don't apply to the logged-in case, also because as soon as I scroll down, all those frills disappears and there's only the text.
It's a content container. A content container that for some of us is now stereotyped as "content in here is often low-quality", which means that in the vast amount of content on offer each day we're more likely to skip links leading to medium.com. If people regularly spread bad blogspot links around, blogspot would have the same reputation. (I'm sure there is tons of spam on blogspot, but when people share blogspot links in my circles they usually are blogs by people that have been at it for ages and care more about content than appearances, so for me blogspot is a high-quality signal)
Being in a known content container is great if you don't have your own "brand" and as long as people associate the container with good content. If they don't, or if your content is way above average, it pulls you down (which provides motivation for below-average writers to write on them, hiding in the crowd, and motivation for good writers to leave)
It is a centralized content container, which makes click-bait titles like this one better material. So you can create a controversial opinion on a subject, get views, make it an entertaining even if exaggerate read and it gets featured among other pieces especially if you use the right popular tags, then your post is on people's medium app and newsletter subscription.
WordPress, on the other hand, is open source software you can host it yourself and thus you can't just slap some tags on it and get featured on top of a newsletter. This is also why some authors prefer medium, easy to setup and easier to get an audience, but then you have to resort to these marketing techniques to drive your views up.
Disclaimer: I have written some medium posts with catchy/controversial titles to test said techniques, call me part of the problem.
There's no difference between debugging REST and JSON-RPC over HTTP, so there's no point to compare them. The other alternatives, that I've mentioned, are less easy to debug.
It takes just a few clicks to generate complete set of requests from WSDL (set, as in "one request per each operation"). I think it's much better user experience than hand-crafting json to use with curl.
The orthodoxy (aka "standard") is there for a reason. It's very easy to shoot yourself in the foot.
If you're only doing small-scale internal interop, especially where you control both ends of all connections, you don't need standards, just do whatever works, but if you have scale dreams, thinking about the rules (What is 'state'? How is it represented? Where?) and why they are there will save you from a lot of headache going forward.
You need a standard within the ecosystem you play in, if only to reduce the amount of work integrating bits and pieces.
For example, I work on an application that has reasonably tight integration between pagination on the front end and parameters / headers on the back end. Works quite well, particularly since we can control both ends. It's not completely ad-hoc - we chose one specific idiom for pagination that had reasonable support, but not necessarily the most widespread - and then extended it slightly when we needed a few operations that had no direct support (e.g. multi-delete, multi-update).
But if you're integrating from everywhere, there's no upside on a unifying standard because any unifying standard will either have so many wrinkles, complexities and caveats to cover every special use case that nobody will implement it correctly or understand it correctly; or it will be ill-suited to many domains, forcing a poor mental model, increasing the probability of bugs and reducing extensibility.
The nice thing about SOAP was it had a full-fledged type system built in. REST is certainly easier to debug, but it's also more likely you'll be required to debug it, since many of the problems you'll run into in a REST interface would have been caught at compile time with SOAP.
SOAP's big problem, IMO, was the crazy insistence on URI formatted namespaces, which took a simple XML message and turned it into something bloated and confusing.
I happen to have worked with the system author coded/maintained. We're not in touch and I'm not here to defend him, but he's no hipster. Rather, he had to integrate a lot of heterogeneous services, as that system was acting like a hub between many departments in the company, with various tech skills and resources. If anything, I suspect he's more kind of unsatisfied by changes that he deemed unnecessary.
As a note aside, the xmlrpc endpoints of the aforementioned system worked fine and saved us time.
I don't remember the history prior to the meeting well enough today to give an authoritative version. So for fear of getting some of it wrong I will say nothing. However, I'll say that the answer to your question is "no".
Having implemented many web service APIs in both SOAP and REST I have the same opinion.
XMLRPC or JSONRPC seem to be the happy middle ground.
The posted article hit home with me as I had to re-implement working SOAP services in REST because you know, management buzzwords and new shiny.
I quickly found, as the article articulates, as soon as you enter the land of verbs and workflows REST starts to stumble and becomes very network chatty. And when that network chattiness is backed by other network chattiness the grumblings of why the hell you can't just return a deep object graph of data from an endpoint ensue.
But you can with REST. Most of this conversation is a strawman against REST. Creating or changing resources can impact other resources. It's obvious / logical. Responses can include the things that they impacted along the way. Much of this thread amounts to "I used this shitty REST API once" or similar for RPC.
Well, it depends on how you reckon REST. I can assure you the real world issues I've run into don't have anything to do with the frameworks used. The impedance mismatch between what one would consider a sane API that could just as easily be implemented as a compiled library and the mappings of that API to HTTP verbs and what is considered proper REST were where the problems were.
My question would be, outside of convenience to SPA developers, what do you see as the specific advantages to REST over XML/JSON RPC or SOAP?
I don’t really remember SOAP since that was over a decade ago, but what I like about REST is that it harmonizes the front end and backend structures of the application and it makes things predictable. It also puts up some guardrails against obviously dumb behaviour like deleting records via a GET and with JSON API, makes it possible for things to snap together once you’ve got the structure right. Ember Data + Rails set up to follow JSON API is just unbelievably productive. Pagination, filtering, optionally including other resources, linking (both to the related resource itself and to the relationship itself) it’s really fast, consistent, powerful, flexible, and secure. It’s not always performant, but when performance is important I make one little RCP or nonstandard REST endpoint (say return a link to a big TSV blob) and I move on with life.
It lacks conventions thoug so every api is more quirky and even sloppier than a bad REST api. At least with REST there’s some existing structure and it’s not completely up to the imagination of someone in a hurry.
If you control client and server and the server's functionality will for the foreseeable future is limited in scope, xmlrpc is the boss.
We had a django/rest based internal microservice. Was a pain to build and maintain. Switched to xmlprc (it's in Python stdlib), removed tons intermediary code, and wrote only a few bits of new code.
This talk by Jonas Neubert opened my eyes to how xmlrpc can be the glue for Python (which is already glue).
Because there is no "booo" button. Every post in medium just have Likes or none, you can like or comment just that, making a critical comment is to much for most of the users that just want to say "I disagree"
If medium has some kind of down vote, it will regulate itself a lot more, and users that disagree will not have to go to make a comment and expose themselves being critical.
Right now is full of "Content Hackers" trying to make reputation.
So long as an article makes a reasonable attempt to present a viewpoint, downvoting does not add anything to the issue. If you disagree, upvote those replies that you agree with (unfortunately, Medium makes that more complicated than is should be.) If no-one can be bothered to say what's wrong with the article, maybe there isn't much wrong with it.
For example, xmlrpc has been recommended in comments as alternatives to consider. Maybe what's wrong with Medium is that the informative replies are on HN... (to be fair, grpc is mentioned on Medium.)
REST is not popular, there are only a few RESTful public API in the wild. The rest (unavoidable pun, sorry) are simple HTTP APIs with JSON serialization which maps with various degree of coupling to internal data layer.
The main cause you don't need REST limitations to achieve same goals.
OP has strong opinion about why we need to reimplement rpc over http every time for every application and write clients for every popular platform to be able to consume it.
Every time I use REST from any google cloud api, my hair is moving and you definitely will have nightmares if you look into their python client code.
I've been curious to see one (for years). Everyone talks about how this REST service is being done wrong, but few will link to services being done "right".
This is the no-true-scotsman fallacy applied to REST. In point of fact, if REST has been around for nearly 17 years and there are so few of these APIs in the wild, then its been incredibly unsuccessful in its aims.
The truth is that these sites are, in fact, RESTful and that REST is just mediocre at what it professes to do. The requirement to treat all operations as resources + HTTP verbs is the primary leaky abstraction that everyone seems to want to gloss over.
The article laid out a detailed explanation of shortcomings of REST. You might not agree with everything in it, but you offer no real rebuttal, instead dismissing it as a “hateful hipsteresque opinion,” without acknowledging any of the actual criticisms the author gave. This strikes me as unfair, haughty and lazy.
It's full of click-bait because of the opportunity for articles to go viral. Spread is built into the platform, so you have people writing the most click-bait articles possible.
>Why is REST so popular? Because it's easy to implement and works for lots of use cases.
Could have given the exact same non-argument for SOAP -- which in its time dominated corporate services.
Whether it's "easy to implement and works for lots of use cases", it's a moot point if there would be something even easier to implement and worked even better for real use cases.
Why stop at "easy" when you can have easier AND more coherent?
Besides, REST is anything like easy. Case in point, almost nobody ever correctly implemented the original REST spec -- that's why everybody calls their implementations "REST-ful", they are some loosely inspired deviations that cargo cult a lot of useless junk.
Supposedly the "real illuminated REST" (like real communism) doesn't even concern HTTP, it's a philosophy beyond web services. And yet's it's all the web related garbage part of the introductory examples that everybody follows (or tries to).
It’s an architectural style defined by Roy Fielding’s thesis (who also was the editor of HTTP/1.1 RFC). It attempted to describe the Web’s architecture in neutral terms and how it was derived by combining previous styles.
Some people took this and crafted a quasi religion out of it, but that’s partly because vendors in 2002 were all lined up trying to replace the web with a CORBA equivalent and then almost succeeded with SOAP/WS-*. People got strident to fight the dollars that were lined up. It’s easy to forget there was no powerful web/internet community with social media and blogging platforms in those days, it was all mailing lists and a couple of conferences vs. Marketing budgets, sales teams, and agenda-wielding engineers on standards bodies from Microsoft, IBM, BEA, Sun, HP, etc.
All RESTful means is that something is attempting to conform to the style. There never was a spec.
>It’s an architectural style defined by Roy Fielding’s thesis (who also was the editor of HTTP/1.1 RFC). It attempted to describe the Web’s architecture in neutral terms and how it was derived by combining previous styles.
It's application for what are essentially RPC needs is which I consider cargo cult.
The people you describe used to have blogs with crappy Wordpress themes that barely got noticed by Google, now they are on a big site so get discovered I guess?
The pain you're referring to is relative to the language you used and when you touched it. SOAP is a comprehensive and we'll defined specification and when implemented properly you forget it's there because it just works.
After about 2003 major vendors had their implementations locked down pretty well. In Visual Studio you just implement a basic controller and the remainder is configuration. If you wanted to consume something from Biztalk, PeopleSoft, any Oracle Product, or any other Enterprise product you could just add a service reference to a WSDL URI and a tool would generate your interface classes and DTO classes for you in your language of choice.
In the Open Source world things were very different. Whenever I would provide a service to be consumed by a vendor, I would provide reference implementations in C#, JAVA, Python, and PHP. I would spend about 15mins on C# and JAVA, then the rest of the day fiddling with Python and to a lesser extent PHP.
PHP and Python have had SOAP libraries for a decade but they require considerably more effort to even consume SOAP. I have never tried to stand up a SOAP Service with them but I can't imagine it's any good.
Around 2012 I remember working with a partner company that was using RAILS for their platform. It was an absolute nightmare for them to integrate with our existing SOAP service layer. SOAP protocol libraries were the least of their issues. No client certificate authentication in their HTTP libraries. No serious XML support. They wrote their own implementation from scratch.
Well, that's actually where the SOAP pain is: it used to be that you couldn't make any good use of it unless you were using walled-garden vendor software. A lot of people dislike Windows, Visual Studio and anything else made by Microsoft. Same goes for Oracle. So then you are left with everything else, which basically means: everything without SOAP, Enterprise editions of runtimes, service buses and the likes.
There are a lot more developers out there not working for an enterprise and not using those tools. Especially the developers doing open source work or doing small scale work.
While nowadays it's fairly easy to make a Java Spring Boot application consume and serve SOAP, with automated WSDL imports and all the WS-* specifics, this wasn't pretty much never the case with anything new and free (as in speech).
> when implemented properly you forget it's there because it just works.
I think that's the link missing for most developers. SOAP was intended to allow machine-generated SDKs to remove all of the sharp edges of dealing with it, and in that regard it was largely successful. What brought it down was the advent of non-"enterprise" web development—development happening outside of a .Net or Java IDE that generated code for you. If you ever had to handroll a wrapper for a SOAP endpoint though, god help you. I honestly believe SOAP was the thing that made XML seem uncool by comparison to JSON and REST. JSON still doesn't solve data representation problems as well as XML, we've just learned to accept "good enough" in its stead.
> PHP and Python have had SOAP libraries for a decade but they require considerably more effort to even consume SOAP. I have never tried to stand up a SOAP Service with them but I can't imagine it's any good.
I've tried suds and zeep. They both didn't really work in my specific cases. My strategy from now on is to write a bit of code in Visual C#, then analyze the xml traffic, and then generate that same XML using Python/PHP. The SOAP protocol is actually pretty simple once you know how it works.
SOAP has a lot of problems, but it's pretty amazing that you don't need a client side library to use it in Visual C#.
REST allows you to make decisions about the http interaction out-of-band, where SOAP provides (and often requires) the ability to describe all decisions about types and parameterization and exception cases in-band.
The REST way allowed one to get started with something small and simple that people could agree to just by talking it over together. With SOAP you had to make all those decisions up front and put it in the specification. I believe SOAP is so complex that it's an analog to CORBA/IDL.
REST is (at least initially) simpler and less specific than SOAP. That's its strength.
> I believe SOAP is so complex that it's an analog to CORBA/IDL.
SOAP was intended to facilitate the same programming model but more loosely coupled. So that's not at all far off. And for what it intended to be—a specification for machine-generated bindings and SDKs—it was quite successful. It just didn't make the usability leap over to web development that happens outside an IDE.
> ...having been through that SOAP pain it's being compared to, I'd say there's not even a comparison
OK, that is indeed the most usual response to "Why REST?". The main reason why people like REST is "because SOAP". It's a false dichotomy that the industry has fallen for.
Oh, yeah, and you can run the GETs directly in your browser/cURL. I like that part too, but it only gives you so much.
REST is more of a philosophy, than a standard. Hence everyone does it differently, and you have no chance to use the same library to talk REST with multiple different services (unless you make that library an overcomplicated beast).
XMLRPC? It's a universal standard, that is just a few pages long and everyone can grasp it in their lunch break. Nobody would complain that your API is not "XMLRPC enough". It works (almost) the same way everywhere. You can get the XMLRPC library that's been built in since Python 2.2 and be reasonably sure that you are going to be able to talk to a random modern XMLRPC API. You'd have other such libraries for every major language. Ditto for JSONRPC, if XML sounds too scary (though it doesn't really matter much - it's a mostly transparent implementation detail).
I'd wish people would stop bringing up SOAP as an excuse for REST. Yes, it was worse, but that does not mean that REST is particularly good.
I don't get why the main thread is an attack to the blogging platform instead of a discussion on the topic.
IMHO REST is not easy to implement, it's easy to say "oh... okay I think I've got it... let me try" but it's very hard to implement RESTful APIs and the author mention a few valid pain points.
Simple use cases like: a user forgot their password, what the proper way of handling this case? A PATCH for a User based on ID? If the ID is a integer ID then you have to query user by email or username before you are able to request a new password, if the PATCH handles this case what other cases does it handle? Can a user request a new password and change their age at the same time, is this a valid case? How you structure your controller to route to these special cases, do you create a custom endpoint thus making your API less restful?
One thing I like about GraphQL is this idea of mutations, in many cases they are analogous to RPC calls, `userForgotPassword(usernameOrEmail) -> forgotPasswordResult`.
You think this guy is a hateful hipster, but most of what he says probably resonates with most software vets. To me, it's mostly against the REST zealots who demand REST is done in a very particular manner. I've seen companies with a very stable, robust RPC framework that had a small faction of REST zealots who were extremely against it because it didn't do things according to REST. It didn't matter to them how stable it was or how well it worked.
Also, REST is relatively not popular - what percentage of the world's APIs use REST do you think?
TBH, you're the one coming off like the hateful hipster to me.
Article reads like being from a crumpy snarky old age dev who lives in his XML-land filter bubble of the 1990s. Go back to XMLRPC and SOAP please. This site is getting more of these corporate old farts lately that don't want to adjust at all. I wish the time back when this site was about startup news, VCs, and new exiting things and not about whining and boring stuff.
We've asked you many times to please comment civilly and substantively, and yet you've continued to repeatedly violate the guidelines, so we've banned the account. We're happy to unban accounts if you email us at hn@ycombinator.com and we believe you'll start following the guidelines.
Okay sorry, yes this comment is over the top, but it reflects my feeling lately on HN.
I tried several times, but it seems constructive criticism or criticism isn't wanted. Proposing changing the voting system to up voting only, and create a report button. The downvoting makes a lot of bad things possible.
Several people sent me mails recently, responding that they fear they would get banned if they write as open and free as I do, and free speech isn't a thing on HN. Well, unfortunately it seems they were right.
And if you verify all the HN news that got moderated/hidden that don't suite your world view, it is appalling. (I don't know if it just the view of two moderators (dang, sctb, maybe a third) or of more people behind.)
In a newspaper I read recently that HN forum is a kind experimental model for Democracy 2.0, and featured as negative example were unpleasant comments get hell banned. Sounds more like communism of the 1970s, than what our country "is" and "needs" as model.
Anyway, I would like to see HN as news site for startups, VCs and SV. Not boring things from corporate IT and PR for them. What's the goal of HN? Cater all, or cater the startups and VCs and Ycombinator? Hint: there is already Reddit, for the rest. Please focus on the first, and move the offtopic stuff to a new "page two".
You shadow banned my account? In case you, a mod, can read this:
Repeatedly? I was questioning if certain accounts are corporate PR drones and downvoting bots, yes. (At least two companies employ very visible a bunch of accounts, and use them to flag/votedown articles and add troll comments to get articles hidden, while they publish "good news" in the very same moment. It's visible on the web, you are in partnership with those companies, and one can guess YC profits from the partnership). But beside that not so much. Unfortunately, two admins never found any evidence, they said, and just said shut up or we ban you. Yeah free speech isn't something on HN. News get marked as hidden every single day, that have many comments and/or high votes, and the two mods never found any evidence and always said "it's the users faults, they flagged it", yeah right, not.
Lots of comments here arguing REST is popular because it's easy, but there's another higher level reason too: it forces you to think about the network.
In far too many RPC protocols, calling functions that operate over a network are treated like normal functions. A function call, almost by definition, fails to take into account network errors, and race conditions where multiple events overlap. Network calls are not function calls, and the fact that REST calls are relatively distinct from normal function calls is a good thing.
However, most of the Getting Started articles that you find about any publicly published REST API usually starts you off with a bunch of curl commands.
Even if the networking aspects are completely hidden from you in your application, your formative experiences with the REST API almost certainly was with the network requests.
Given the dozens of languages and libraries that interact with APIs, I don't see the issue of starting with a curl command. It's a common denominator, programmers of almost all languages understand, like international sign language. No one would seriously use curl commands in production, but load up a command window, and it's an easy way to start messing around.
Agree with your second point though... network requests are hard. They are not much different from real distributed programming. Making REST requests should be done with care.
I do use curl commands in production for stuff like user data in an aws cloudformation template. Having an api I can hit with curl that returns json I can parse with jq is super convenient.
I don't think the parent commenter sees curl-centric getting started guides as an issue either. Actually from this thread's context I assumed they thought it was a good thing.
If a network (or endpoint) fails you usually only few options during runtime, retry, skip, stop. That is pretty much all you want to know. Everything else is specific to the endpoint, which is more about contracts and constraints then about networking. You either use the endpoint correctly of not. I.e. using a database like MySQL has similar constraints. And decent engineers know how to work with it and where it is happening.
Yep, and no amount of REST / other introspective boilerplate can help about the fundamental problem of not being synchronized.
There is no solution to the "A knows X, but B does not know that A knows X, or A does not know that B knows that A knows X, or B does not know that A knows that B knows that A knows X..." problem.
Other than that, I think at some level networking is nothing more than function calls that can take a long time and/or fail.
I worry that this is something that can be applied to programming in general these days.
Back in the day of the C64 etc, programmers had to worry about the underlying hardware as they were for the most part working with assembly.
But as increasingly abstract languages have come to be (most modern ones use virtual machines and garbage collectors), the programmer never have to consider the hardware their code has to interact with at some point. End result is all manner of bloat and memory leakage.
I don't think you closely read what parent wrote. Do you think a function call is "too abstract" because "nobody knows what it's doing under the hood"?
The article talks about how to communicate between systems. But many systems don’t need to be distributed.
If you can avoid writing a distributed system, that’s easier than even a “better REST”, if such a thing were to exist.
For example, old-style non-SPA web applications, can directly use underlying logic classes directly, can throw exceptions, need not serialize data, one connection to the DB with one transaction capable of rollback, and so on.
Or monolithic servers rather than microservices.
Sometimes you need RPC, but for those situations where you don’t, avoiding RPC completely is a significant reduction in complexity.
REST can be as simple as you want it to as verbose and rigid as you want it. Defining an API has certain public expectations such as request/response and basic HTTP status codes, but again can be easy or more detailed. There are RESTafarian and pragmatic ways to implement REST APIs.
Much of the problem of any tech becomes that engineers/developers are supposed to make complex things simple but instead sometimes make simple things more complex because it seems smarter. Complexity is needed only enough to make it simple to interface with and consume. REST is an example of web services done right and more simple compared to SOAP which was supposed to be the Simple Object Access Protocol but they forgot the simple part and just kept adding layers.
APIs should be easy to work with and as non changing as possible in the public signatures and routes/data/configs or else versioning should come in on major changes which should be handled wisely. Sometimes that is RESTafarian or pragmatic, sometimes more HTTPRPC, sometimes that means schemas for consumption, sometimes pretty urls, sometimes ids and name blurbs, sometimes responses wrapped in app messages/wrappers, sometimes directly on HTTP(s) response bodies, and it all depends on if it is public or private and if you control both endpoints, the clients and business needs.
I think there’s a tendency in software for people to start out without understanding all the complexities they’re going to encounter. I think this is just human nature.
When you start out doing RPC you think, I don’t want to bother with schemas, I don’t want to bother with hierarchical error codes, I don’t foresee the need to set the user’s password but not retrieve it. So you don’t want to bother with a technology which makes your life more difficult, to solve problems you don’t have and cannot foresee.
So you choose something simple. But you run into all these problems anyway, because they exist, no matter if you were capable of foreseeing them or not.
But by then it’s too late. You’ve written 50 KLOC and you just have to keep going.
I believe this is why many technologies become popular which are actually too simple to handle the types of problems they try to solve.
You're right of course, like the first time you hit a race condition (with a week of debugging) and build a distributed lock system. You publish it and people find it useful!
Only to realize later postgres offers fine locking capabilities far beyond what you've created (now that you get it).
Then you realize that all anybody is doing is creating subsets of Erlang (half serious). So why aren't we all using that?
In the grand scope, is it really a bad thing?
We end up with X ways to solve problem Y and you never know X + 1 could have some advantages. Exploration should be encouraged IMO!
Unfortunately, we get a whole lot of ad-hoc, informally-specified, bug-ridden, slow reinventions of the wheel for every better mousetrap. Usually (though not always) the best simple solutions come from those who understand where the complexity lies.
I think that approach of creating abstractions and concepts just in time is good tbh. It allows for thing to get incrementally complex. I wish there were a way to manage concepts through that process so that you could have all of the simple, easy to change stuff for new concepts while using the more comprehensive and often complex stuff for more "hardened" concepts.
Then you have phase two of engineer development, where having been burned by something surprising engineers overbuild everything. That's when you get technologies that are too complex to handle the problems they try to solve. That's when you get seven layers of dependency injection for something that could be a single-line algebraic statement with five variables.
Yup. It's the mechanism behind programming as a pop culture. Kids without a lot of experience are sick of the old way because it's too hairy and complicated, they come out with a fresh new approach that isn't nearly as broadly applicable, then it gets improved until it's fit for general purpose, at which point it's hairy and complicated and the cycle starts again.
I don't think that everything is standing still, though. Usually each successive generation has an edge on the previous one; either the previous generation was constrained by memory or CPU or bandwidth and had self-limiting architecture because of it, or the next generation needs to solve a problem involving an order of magnitude more data or compute and it needs a different approach.
But, of course, not everyone (or, realistically, not many people at all) is constrained by the thing that causes the revolution; people usually just get on the bandwagon because you must, if you don't you won't be as employable, won't be as hip, you'll find it harder to employ engineers to work on your project, etc.
"All good solutions to existing problems have been discovered. There may be new problems which need new solutions, but no one will ever improve on what we have already done. Anyone who things they can is a child playing in the dirt."
One element of it is also that in many cases the path to "becoming big" starts with bootstrapping and experimental projects that you may not know if it is going to survive and exist in a few years or if you are going to throw it away in 3 months.
So in those cases you may still choose to be scrappy, knowing that it will come back to bite you, but at that stage that is thought of the success scenario and a good problem to have (if it happens at all).
This is in contrast to large serious projects for large existing companies where you can much more confidently know that X and Y are going to be required because from day 1 you know the project is not just some casual thing.
This is also why I think the software creation process and tools need to seriously think about having adjustable safety/pain knobs to allow for cheap scrappy prototyping but also allow to tighten the screws for production.
You can kind of see a glimpse of this between various programming languages, particularly in their type system. But the general concept is broader than just that.
It occurs to me that young people may be better at bootstrapping in a scrappy way, because they don't yet have the knowledge and experience to immediately consider all the things that would be required in a mature implementation. Speaking for myself, now that I'm approaching middle age (37), if I contemplate developing a new product from scratch, I risk paralysis by analysis, overthinking every aspect of it. I certainly didn't do that when I was 21.
Scrappy bootstrapping is a double-edged sword. On the one hand, it brings us great new products. On the other hand, ignoring some real-world concerns can be a major problem for users. As just one example, consider the impact for people with disabilities (e.g. blind, mobility impaired) who need to use an app that was developed with no regard for accessibility. And I've blissfully ignored other real-world concerns myself. For instance, the first desktop app that I worked on (in my 20s) had no support for HTTP proxies (as often found in corporate networks back then).
> "Any sufficiently complicated X contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Y." (where X is the new "simple" way and Y is whatever the greybeards are using.
That's exactly what YAGNI/KISS encourages. Don't make things more complicated than they need to be right now. That includes used technologies.
I'd much rather use a simplistic tool while I still get away with it, risking having to switch to a more complicated tool later, than starting off with something way too complicated for what I need.
Chances are the difficulty isn't in switching from REST to SOAP, or the other way around, but in dealing with the all the assumptions that permeate those 50 KLOC. In the end it just comes down to having a clean code base that can be steered in another direction.
Note that I only mean not dealing with what cannot be easily be foreseen. Turning a blind eye to what you should know will soon be a problem, is a different story. As an example, if you ignore concurrency from the start, that will be hard to set straight later.
But you can't just decide to avoid making assumptions, because the shape of your API strongly dictates the shape of your handler methods. I've never seen an API migration that didn't involve rewriting nearly the entire API layer.
Even worse, you have to maintain both the old and new versions of the API code, because turning off the old API endpoint is going to take at least a year.
We now recently had to design an internal system to manage student data. We went with REST and the first thing I did is to document all API-s in a repository using Swagger.
It's not really true that there are no standards, they defined Open API, it has a nice browser based editor to update the YAML files and it's easy to read an maintain.
All changes to the API-s are done via pull requests, so changes are reviewed.
The HTTP verb is also a non issue, there's 4... FOUR that you need to match with CRUD. Is that hard? Even if it is, read the docs.
REST is freedom (with all its downsides when you can do what you want), SOAP is like military (with all its strong rules).
It's like comparing a micro web framework with a full web framework.
I think it always depends what you want to do in which scale with REST. What's great for a single hobby developer would be bad for a big world wide corporation.
If you really want more rules, more restrictions and more boundaries for 100 of developers working on your project you should definitely look on something build on top of it (graphql, odata) or one of the replacement architectures like grpc if you have high demands in your infrastructure.
For me as a developer I'm always happy when things are not overcomplicated at the beginning, but some developers like more structure down the road. At the end you need to get stuff done and I think it's better to educate yourself about REST in general than some big other framework which you need to implement somehow everywhere.
This is really tangential, sorry, but I'd like to mention that the (US) military is strongly opinionated in a relatively small number of ways. Additionally, the rules are self-enforced throughout most of its structure, and almost none of the rules being broken will cause the system or its components to fail. The US military is actually incredibly flexible, because the (mostly) self-enforced strong opinions inform the decisions of subsets of the military all the way down to the individual level, allowing each component to be effective almost regardless of the health of the rest of the system. SOAP was incredibly inflexible. I think perhaps a better analogy would be to compare SOAP to some defense contractors, where things must work a certain way, or they grind to a halt and become very expensive to debug and triage. Also, incidentally, I'm interested to hear about your experiences with gRPC. I have just played with it, but it sounds like you had some issues scaling with it? Or didn't like it so much? I much prefer REST because of its inherent flexibility, as you do, but I am interested to hear from people who scaled with gRPC.
Yet another discussion where people talk past each other because everybody means different things by "REST". It certainly is not the "REpresentational State Transfer" as invented originally.
It is hard to evaluate an idea without being tied to an implementation. How would you evaluate Monads as an idea without talking about Haskell?
The primary problem with REST is that most people learn it by example. Then they believe it is about web services returning JSON or about pretty URLs. It is not.
I hate working with pedantic programmers who chastise you for using the wrong http method or not formatting url's correctly because it's not restful, and then few years later jump onto some new tech, like graphql or something else, and then evangelizing the new religion. That's how some "senior" devs maintain their importance, using this esoteric knowledge to keep lesser programmers out. And if you try to catch up, you're playing a fool's game, by the time you learn all the peculiarities of their interpretation of "RESTfull", they have already jumped to GraphQL. Same for React (remember this one - presentation (HTML) and logic (JS) should not mix!?), but now that we've switched from backbone to react, suddenly it's ok. It also applied to random methodologies like agile, scrum etc. A lot of cargo-culting, and not a lot of actual engineering.
> You want to use PUT to update your resource? OK, but some Holy Specifications state that the data input has to be a “complete resource”, i.e follow the same schema as the corresponding GET output.
If you were working in a strongly typed language with RPC calls, you would see the same problems, or symptoms thereof. For example, if you had the two RPC calls storeFoo and retrieveFoo, you'd expect them to both take Foo objects, no? Something like,
and PUT/GET in HTTP yearns for the same dichotomy.
> So what do you do with the numerous read-only parameters returned by GET (creation time, last update time, server-generated token…)? You omit them and violate the PUT principles?
Yes, and just call it POST, since it's no longer symmetric and violates PUT principles. REST has nothing against POST. Again, this problem would be reflected similarly in RPC:
(or perhaps storeFoo ignores some fields on Foo, etc.)
> creation time
This is a fantastic example, because I actually had this problem w/ a non-RESTful API. We took a generic sort of "create record" and recorded the current time as the "start" time. The problem was when the device lost network connectivity (which was essentially always, just a matter of "how bad is the latency): the creation of the record would lag, sometimes by hours, and the eventual "creation time" it was tagged with was wrong. We should have trusted the device, because it knew much better than the server when the actual record was created.
Now, this isn't going to be the case all the time; sometimes you literally want just the time the DB INSERT statement happened, and that's fine.
> Pick your poison, REST clearly has no clue what a read-only attribute it
POST a "create" request, GET has the newly created fields. Symmetric PUT/GET is nice, but show me where in HTTP it is recorded as an absolute.
> Meanwhile, a GET is dangerously supposed to return the password (or credit card number)
Not only does REST not dictate this, nobody in their right mind should do this. GETs just return the resource. What that resource is, what data is represented — that's up to you in HTTP just as it is in RPC.
> lots of resource parameters are deeply linked or mutually exclusive(ex. it’s either credit card OR paypal token, in a user’s billing info)
and you're in the same hot water, again, just with RPC. If your type system allows it, you can make them mutually exclusive there, perhaps something like,
but then, that cleanly translates back into a RESTful API's information too. Now, JSON is typically used, and it doesn't really expose a real sum type, which is a shame. You can work around it w/ something like,
and it works well enough. If you can't express it in the type system (in either RPC or REST) then you have to do some validation, but that's true regardless of whether RPC or REST is in use.
> you’d violate specs once more: PATCH is not supposed to send a bunch of fields to be overridden
…how is that a violation of the spec?
> The PATCH method requests that a set of changes described in the request entity be applied to the reso...
Decades of horrific developer pain disagree with you. The “tools@ all have different ideas of what is correct, good style, the right name spacing and encodings...
We’re about the same age. How is it that you’ve not experienced the same horrible almost-but-not-quite interoperability messes with XML and SOAP that I have over the last 20 years?
Maybe REST was the best protocol for the great public API explosion of the past decade, where startups wanted to expose a public API to anyone on the internet. The most important requisite was that the most developers could access the API with a minimum of technical knowledge and tools, and the APIs were simple. I am less and less sure that REST is the best solution for communicating between internal services, which know a lot about each other and where you can spend time onboarding developers on a specific techniques and stack.
I don’t know yet because I haven’t had as much experience with other solutions as with REST. I am curious about Thrift and Protocol Buffers. I have worked once on a project migrating from REST to Protocol Buffers for an internal API and it noticeably improved performance, but code complexity remained more or less the same.
Well, REST is architecture. Protocol Buffers are (de/)serialization.
I've tried it before (& although it has the properties I like[language agnostic schema definition..]), it was finicky to get working with of one the biggest IDEs out
there(IntelliJ IDEA)
Also, it doesn't support Kotlin yet.(Java interop only option)
The only place I can see Protocol Buffers being useful is inside Google..cos it was a pretty crappy dev experience.
And I would be pretty confident in saying that not many Googlers/ex-Googlers outside Google use it. Cos if they did, somebody would make the dev experience much much better.
I use protobuf at work all the time (not google) and prefer them over almost all other serialization formats. To be fair, I mainly work in Scala, C# and JavaScript where great implementations exist. In the case of Scala, IntelliJ just needs to know that the generated source files are just that and then it „just works“ for me
XMLRPC with WSDL was bad enough that I only had to use it once. We migrated WSDL stack to REST (2007-8), which was an improvement, but it was fraught with a fat clients for each language integration to uniformly handle SSO authorization and other sundries.
Has the author considered something built upon Protocol Buffers, which have can have reasonable versioning semantics and is portable and supports status code canonicalization, like gRPC?
What was wrong with WSDL? I also only used it just once or so, but found it to be transparent. Generated a client (set of functions) for two languages and never touched the WSDL or SOAP directly afterwards.
CORBA is the best protocol I ever dealt with. Strong contractual semantics, exceptions, interface definitions. Spiced with transparent compression, encryption and bi-directional communication. All those goodies were already available 12 years ago.
The only downside - it required a reliable and precise implementation that took a lot of efforts. I always used IIOP.NET for most of my gigs and it was excellent. I also ended up as an active IIOP.NET contributor.
CORBA ORB implementation was a fine art a few could grasp. And this was the biggest drawback - the standard was (and is) excellent, but most implementations tend to be complex and shaky.
I still actively use CORBA. The server usually offers two kind of endpoints: REST for third-party integrations (which are usually naive and simplistic), and CORBA for the system itself. I've built nice things with such architecture that involved worldwide deployments including embedded hardware. I am very proud of my involvement and the fact that I could help to improve the everyday routine for many people worldwide.
Thanks for this input. I always love reading things things that get me excited to try and look into stuff I have previously discarded for probably "popular" opinion.
I was somewhat involved with CORBA in its early days. It had some very smart people driving it. It was derived from work already being done by the large companies like IBM, DEC, Apollo, Sun, HP, and Microsoft.
But CORBA was haunted by a key principle that limited its influence. Unlike the IP protocol stacks, which are layered from the lowest wire protocols on up to the highest layers, CORBA dictated the highest level protocols and didn't address the lower level protocols. Different CORBA implementations couldn't talk to each other; consequently, CORBA didn't work for my company because we were was trying to design a product that could work across heterogeneous networks of workstations and servers.
If the CORBA folks were so smart (and they were), how could this happen? Why didn't they design the original CORBA protocols from say UDP or TCP on up? The CORBA members were all from different companies, and all had different independent products. There was fierce competition in this space so it was impossible for the members of CORBA to agree on the low level networking protocols because doing so would harm some companies' product lines while benefiting an others.
350 comments
[ 2.9 ms ] story [ 258 ms ] threadHonestly, REST is a great idea. Yes, people get religious about HTTP verbs and URL structures. But you don’t need to. Prioritise clarity to humans above everything else, and you’ll be fine for the most part.
I've seen this argument before (I've even made this argument before), but I'm becoming increasingly unconvinced by it. Let me explain my thinking:
1. If there's ANYTHING that sets REST apart from a generic HTTP-and-JSON protocol, it's the focus on basing endpoints off the concept of resources and collections, and using HTTP verbs to determine the type action to be performed. (And also, possibly, internal hyperlinks, but nobody seems to actually pay attention to that part.)
2. Depending on your application, somewhere between "some" and "most" of your API traffic doesn't deal things that easily map to resources and collections, doesn't involve actions that easily map to HTTP verbs, or both. One of the most common examples is sessions. When you log in, are you creating a session resource? Is that a sub-resource of the user resources, or an independent collection in its own right? Or are you actually retrieving a session token from the user resource? When you log out, are you actually deleting that session? Or updating the session to remove its authentication?
3. It's easy to say "prioritise clarity to humans", and I totally agree, but in that case, you'd just have a /login and /logout endpoints, you'd do a POST to the former with a valid username/password to login, and a POST to the latter to log out, the end. That's super clear, and super usable, but nothing about that is RESTful. And the same thing comes up over and over again. For every time I find myself doing simple CRUD operations on a collection of concrete resources, there's 10 times I find myself needing to do complicated, ambiguous operations on things which aren't.
4. But if I relax and focus on making a clear, usable API, then almost by definition I have to do so by not being RESTful. It's easy to say that you shouldn't get religious about HTTP verbs and URL structures (and I agree), but since HTTP verbs and URL structures is 100% of what people seem to mean by "REST" in actual practice, then...in what sense is REST a good idea? It's like drinking rum and coke without the rum...and the coke. What's left? Nothing Roy Fielding would recognise, in my view.
I'm happy to entertain the idea that REST is useful when you are doing CRUD operations on simple, concrete resources (updating prices on an online store; posting comments to a blog; whatever). But in my personal experience, most people seem to view REST as the ideal way to handle making an entire API, even the bits that are clearly nothing more than RPCs triggered via HTTP.
And this is the beauty, compared to SOAP: you can mix-and-match. Make your resources as RESTful as possible (but e.g. omitting passwords/cc numbers), and implement the stuff that's not resources in good ole plain-json way.
For logins there's no other choice anyway, given the tons of different ways: some are email+password, some username+password, some add a tenant parameter to the mix, some add one of the dozens of captcha solutions, some want Oauth, various 2fa schemes, ...
Bits of your application that have natural nouns - “post”, “credit card”, “product” - fit naturally to endpoints. Log in doesn’t, so don’t try shoehorning it in. If only 80% of your application can be defined as REST level 4 but is clear and easy to use, who cares? And if your domain doesn’t fit well with REST, then don’t use it!
Personally, if I have an object like “product” and want to use some custom verbs, I include them in the “links” section of the product response. My authentication process is in the documentation, with /login and /logout URLs.
My first priority is always to make something usable by humans. I try to do that using REST wherever possible, because usually those goals go together. When they conflict and I can’t resolve them, I choose usability by humans over strict REST principles.
Nothing bothers me more than an idempotent request (e.g. a search query) using POST. If you design your API starting with "what should happen if the client makes this request multiple times?", then it becomes much easier to model with HTTP.
HTTP 401 Unauthorized actually means Unauthenticated. 403 Forbidden actually means Unauthorized. Yeah, it is a bit of a mess but the referer header is misspelt so what can you do.
Why not?
> A payload within a GET request message has no defined semantics;
> sending a payload body on a GET request might cause some existing
> implementations to reject the request.
https://tools.ietf.org/html/rfc7231#section-4.3.1
if the request method does not include defined semantics for an entity-body, then the message-body SHOULD be ignored when handling the request.
Now, RFC 2616 is obsolete, and I couldn't find such explicit wording in the superseding RFC 7231. But §4.3.1 (https://tools.ietf.org/html/rfc7231#section-4.3.1) says:
A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request.
Source: https://tools.ietf.org/html/rfc5789#section-2
"I don’t care. Trees are recognized by their own fruits. What took me a few hours of coding and worked very robustly, with simple RPC, now takes weeks..."
He seems unhappy that REST doesn't work the way his familiar tool (RPC) does. I myself worked with middleware-messages-over-TCP systems for a decade before switching to web apis. I don't have this issue. And I personally don't follow the "holy specification", and REST works just fine for me.
RPCs make it easy to get started on a dev machine. making network calls appear like function calls definitely speeds things up when the network is working perfectly, but it papers over the complexities of debugging network issues and complex distributed race conditions, which will inevitably come up later.
Being explicit with network communication has its benefits.
(corollary: for the same reason as above, I don't like lazy evaluation of database queries that exist in many languages. When you hit a database, it should be intentional, you should know about it, and should properly prepare for any necessary network issues, caching, and cursors. Many modern web frameworks gloss over this).
Anytime a computer program consumes a potentially scarce resource (e.g., network, disk, database, etc), there should be some warning-sign or flag raised to the developer. RPC hides that, whereas REST makes it more explicit. So much of programming is social, and the mechanics of REST, even though theoretically identical to RPC, raise many social flags warning of danger ahead.
It's worse if not only statements are longer, but you are actually forced to treat similar things in very different ways (like URL resource vs query string vs post parameters). It just increases code complexity without any clear benefit.
Oh, and for those who want to be able to query APIs from the command line without prior knowledge, the following works if you have reflection enabled on your gRPC server:
Clients are lazy and impatient, and this is a good thing because it makes the developers work hard to make it easy to connect to their API.
After moving to a REST based API there were endless meetings between co-workers of what is and isn't a good REST url. Our clients often come to us with dumb mistakes. Unlike RPC where the parameters go in a single place. With REST the parameters are spread across the verb, url, header, query param, etc..
With RPC your consumers probably need to know some coding and even maybe a specific language, a framework or a library.
So yes, for me REST is easier, and I always love to see landing pages like this one - https://freegeoip.net - where the client can test the API in a few seconds by copying an example to its browser address line. This is a simple use case, but I hope you get my meaning.
SOAP even has handy discovery tools that frameworks can consume and construct entire APIs in most popular languages.
It's just that no-one uses SOAP from a browser because XML is a royal PITA to write in JS. I would assume it's because all JS developers are too-busy writing more libraries-for and layers-over JSON.
You can argue that REST is easier to debug for developers, but nothing makes XML-RPC or binary protocols inherently _less_ easier to debug. It depends on the platform and library you're using.
I wholeheartedly agree with the article. Well done.
And the wide availability of those is because it's so easy to build one over obvious REST apis.
{“username”: “sam33”, “password”: “hunter42”}
Would be fine, but could include more if you were following a spec like JSON API 1.1. I really don’t have any of the problems you seem to have. But I work in a high level programming language, so maybe it’s that? Either way I find RCPs to get messy when they get bigger. Sometimes it’s the right move, but for web apps I generally prefer REST.
Subconsciously no one wants to deal with your carefully constructed REST URLs. They just want a function name and some parameters.
A good example to me is Stripe.
I've written over 10 applications that use Stripe and every single time, the first thing I did was use Stripe's official library for the languages I work out.
"Async RPC" is a more recent idea, but still gets referred to as "RPC", so the complaints about classic RPC still get raised since the term is overloaded.
In theory, the latter does the same thing, but it's far more explicit, the developer knows it relies on the network and accordingly that it may fail. Developers will be more inclined to plan for errors when the possibility of such errors are more obvious.
So in most cases you'd do something like:
Is it really a useful distinction? Let's rename our 'foo()' to 'dangerously_unreliable_with_unpredictable_latency_foo()'. Is there still a huge difference?
> accordingly that it may fail. Developers will be more inclined to plan for errors when the possibility of such errors are more obvious.
That part of your comment looks suspiciously similar to the usual argument against exception handling to me.
And to your second point... yes, all developers should check possible exceptions, just like all children should brush their teeth. However, if you have bad habits and you aren't good all the time, then at lease brush your teeth after eating sweets, and likewise, developers should please check for exceptions around network calls.
Access the RPC call as httpSerbice.getFoo() and make it return a Future/Promise, or even a special subtype of those. 100% obvious what it does.
You're going to be calling REST methods the same exact way anyway - you have to pass around the result of that restful http.get call somehow.
I don't see RPCs as anything different conceptually (after all the job might also fail). The only issue someone might have is when expecting a synchronous API, but even in non-networked code there are tons of asynchronous APIs.
The goal should be to inform the caller of the types of errors that may pop up. Obviously, with network or RPC calls, the caller should handle the case where the network is down. With threaded apps, the potential errors are more subtle, but the caller should definitely be aware that it's not a synchronous call. The function header you proposed is a bit clumsy due to the c semantics, but gets the general point across well enough.
The part I find most interesting about Fielding's thesis[1] is the introduction with architectural overview. He managed to map out modern Web apps perfectly - they can be REST (Web app with db/storage backend, perhaps extended with something like webdav) which is amenable to multilevel caching, smart client;movable data: json api js app, or smart client;movable code: js/Ajax - executing js delivered by server on client (subtly different from a "pure" js/json app (which is similar to an XML/xslt App).
I don't know why the hype of rest lead people to insist on conflating their architectures.
[1] http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
Ed: not sure about "time wasted bickering over it". Bickering is always time wasted. Careful analysis of software architecture, patterns, and figuring out what you're actually trying to achieve - is time well spent.
There are fundamental trade-offs between REST and different patterns - depending on where the truth of your data recides, if you need acid or not, and where (what part of) your code executes.
> Don't get me started with conflating http server errors with applications errors.
I've wasted so much time dealing with 404 errors that were returned by the webserver itself (not the app) because the endpoint I was hitting was wrong or had moved, and vice-versa when I was correctly hitting the app but got a 404 error back from the API and I thought that the endpoint was wrong. And, of course, similar issues for 500 errors and the app itself dying versus the app processing normally and indicating an expected failure response via a 500 error code.
To add to all that badness, a lot of JS libraries in their async API method calls have different error handlers for success and for failure response codes, so you end up having to lump together business logic (for resources not found) and retry/error-handling logic (for the server the not working correctly) into the same failure response callback handler. It'd be much cleaner if all the business logic could be handled in a single callback and all of the failure logic could be handled in another. And, of course, you only even get to this level of badness once you figure that out; you can still waste quite a bit of time before you even realize that your callback is not being called because the JS framework is interpreting the expected 404 your API endpoint is returning for non-existent things in business logic differently than you are.
I still wouldn't go back to SOAP, but I do tend to prefer HTTPS/JSON-based APIs that don't abuse verbs, HTTP error codes, and mixes of URLs/params/headers/payloads. Better to put all of that stuff inside the JSON payload where it will only be handled by the application business logic, rather than mixing it in with all of the HTTP constructs that are used for other things as well.
It was the same way 15 years ago if you suggested anything other than SOAP. The more things change, the more they stay the same.
The thing is, RPC is fundamentally broken due to the nature of distributed computing, and REST is not. All the time you have to spend doing things right is … the time necessary to do things right.
And REST really is very simple. The problem is the cargo-cult nature of folks who don't really understand it.
I must’ve spent hours of my life poring over the Wikipedia HTTP Response Codes page, looking for the most expressive error code for my situation. It’s barmy.
For some APIs, it definitely does make sense to use proper status codes, but for others, it's like fitting square pegs into triangular holes.
Just add a code, it's seconds of work.
Not really, I just don't
In general, the key point as about working in a generic way, given that it's so simple.
I don't like the idea of returning a human readable message that says there was an error but a machine readable message that says everything was fine. I have far too many cases of having to deal with human text explaining that a value is missing already in my data.
Yet the official name for 401 is 401 UNAUTHORIZED.
So even the very basics of REST and HTTP are confusingly or ambiguously defined.
Meanwhile, 403 seems to be reserved for when the server just generally doesn't want to do what you're asking it to do. It may tell you, it may not, it doesn't have to tell you, so there. "Authorization will not help..."
tech industry: you're not doing x right.
everything should be a suggestion to consider not a rule. otherwise it's just dogma.
What is with medium.com? Why is it so many links to this site are full of hateful hipsteresque opinions looking to sound smarter and more insightful than they actually are?
It may have to do with the platform being used by individuals trying to create a brand of themselves, resulting in a high percentage of sensationalist and controversial posts. Along with the necessity to write on a regular basis.
left: it gets stuff done because it's smarter
right: it's bad for you, it's actually getting less done
middle: didn't read all that stuff, busy getting stuff done.
I agree with this. When I end up on a new project and I'm not the lead, and there is a lead who is pedantic regarding how they want their URLs crafted (or wants to implement a complicated query pattern, or introduce an extra layer of objects to satisfy an abstract notion of purity), I'll just go with the flow. Accidental complexity, pattern seeking and cargo-culting are personality traits of many programmers, and I've come to the conclusion that its best to accept this, and get on with the job of actually delivering value.
Cargo cults are not good. Finding and adhering to regular patters that logically underlie what you do saves time and mental effort, while also preventing certain classes of errors. (No, these are not GoF design patterns.)
Finding the balance between pointless over-engineering and rigidity on one hand, and good software design on the other, consistently, is what seems to distinguish great programmers I’ve worked with, from those who are “just” very good.
But, like I said, it often isn’t worth the trouble fighting about these things, even when we see them, and getting on with the job is more important than ensnaring oneself in religious debates on projects.
Having shitty paradigm is certainly better than having none at all. But at some point we have to evolve.
Read. The. Damn. Stuff.
And what's with the UI on their publications. They take up top 25% of the screen with the branding and navbar and bottom 10% asking me to sign in and both sticks on the screen. Who approved that?
https://userstyles.org/styles/browse?search_terms=medium.com
then, it's only alt-B -> 1 away, in Firefox
Personally I will keep using REST. If I ever find something is too CPU or network hungry with http/JSON I will take a look at a binary protocol.
For me REST has opened up the world of web applications to simple integrations. It is what makes simple, single use case web apps useful.
Agreed, its a content platform with a where the content fights for attention with the medium.com branding. How many people do you really "never miss a story from"? I generally avoid medium.com for this reason alone.
I'm further puzzled when I see companies using medium for their company blog as well. All I can figure is it must be recommended in some user guide to "growth hacking."
https://github.com/thebaer/MMRA
Being in a known content container is great if you don't have your own "brand" and as long as people associate the container with good content. If they don't, or if your content is way above average, it pulls you down (which provides motivation for below-average writers to write on them, hiding in the crowd, and motivation for good writers to leave)
WordPress, on the other hand, is open source software you can host it yourself and thus you can't just slap some tags on it and get featured on top of a newsletter. This is also why some authors prefer medium, easy to setup and easier to get an audience, but then you have to resort to these marketing techniques to drive your views up.
Disclaimer: I have written some medium posts with catchy/controversial titles to test said techniques, call me part of the problem.
Once people start exhibiting excruciating pedantry in designing their APIs, I'll switch off somewhat.
Many languages support auto generation of consumer and producer code based off of WSDLs.
And AFAIK, most languages that don't have the auto gen tools do have XPATH libraries for easily manipulating templated SOAP requests.
It takes just a few clicks to generate complete set of requests from WSDL (set, as in "one request per each operation"). I think it's much better user experience than hand-crafting json to use with curl.
[1] https://www.soapui.org/
If you're only doing small-scale internal interop, especially where you control both ends of all connections, you don't need standards, just do whatever works, but if you have scale dreams, thinking about the rules (What is 'state'? How is it represented? Where?) and why they are there will save you from a lot of headache going forward.
For example, I work on an application that has reasonably tight integration between pagination on the front end and parameters / headers on the back end. Works quite well, particularly since we can control both ends. It's not completely ad-hoc - we chose one specific idiom for pagination that had reasonable support, but not necessarily the most widespread - and then extended it slightly when we needed a few operations that had no direct support (e.g. multi-delete, multi-update).
But if you're integrating from everywhere, there's no upside on a unifying standard because any unifying standard will either have so many wrinkles, complexities and caveats to cover every special use case that nobody will implement it correctly or understand it correctly; or it will be ill-suited to many domains, forcing a poor mental model, increasing the probability of bugs and reducing extensibility.
SOAP's big problem, IMO, was the crazy insistence on URI formatted namespaces, which took a simple XML message and turned it into something bloated and confusing.
As a note aside, the xmlrpc endpoints of the aforementioned system worked fine and saved us time.
Xmlrpc is soap without the bullshit.
I built lots of personal apps that were flash/flex front ends that talked to python backends over xmlrpc to quickly whip up his for my python aps
I remember well the meeting when things started to go off track...
XMLRPC or JSONRPC seem to be the happy middle ground.
The posted article hit home with me as I had to re-implement working SOAP services in REST because you know, management buzzwords and new shiny.
I quickly found, as the article articulates, as soon as you enter the land of verbs and workflows REST starts to stumble and becomes very network chatty. And when that network chattiness is backed by other network chattiness the grumblings of why the hell you can't just return a deep object graph of data from an endpoint ensue.
My question would be, outside of convenience to SPA developers, what do you see as the specific advantages to REST over XML/JSON RPC or SOAP?
If you control client and server and the server's functionality will for the foreseeable future is limited in scope, xmlrpc is the boss.
We had a django/rest based internal microservice. Was a pain to build and maintain. Switched to xmlprc (it's in Python stdlib), removed tons intermediary code, and wrote only a few bits of new code.
This talk by Jonas Neubert opened my eyes to how xmlrpc can be the glue for Python (which is already glue).
https://www.youtube.com/watch?v=cEyVfiix1Lw
If medium has some kind of down vote, it will regulate itself a lot more, and users that disagree will not have to go to make a comment and expose themselves being critical.
Right now is full of "Content Hackers" trying to make reputation.
For example, xmlrpc has been recommended in comments as alternatives to consider. Maybe what's wrong with Medium is that the informative replies are on HN... (to be fair, grpc is mentioned on Medium.)
Twist on “easier to destroy than create.”
REST is not popular, there are only a few RESTful public API in the wild. The rest (unavoidable pun, sorry) are simple HTTP APIs with JSON serialization which maps with various degree of coupling to internal data layer.
The main cause you don't need REST limitations to achieve same goals.
OP has strong opinion about why we need to reimplement rpc over http every time for every application and write clients for every popular platform to be able to consume it.
Every time I use REST from any google cloud api, my hair is moving and you definitely will have nightmares if you look into their python client code.
The remainder.
I've been curious to see one (for years). Everyone talks about how this REST service is being done wrong, but few will link to services being done "right".
The truth is that these sites are, in fact, RESTful and that REST is just mediocre at what it professes to do. The requirement to treat all operations as resources + HTTP verbs is the primary leaky abstraction that everyone seems to want to gloss over.
They can have the same root cause though: someone's identity feeling threatened.
Could have given the exact same non-argument for SOAP -- which in its time dominated corporate services.
Whether it's "easy to implement and works for lots of use cases", it's a moot point if there would be something even easier to implement and worked even better for real use cases.
Why stop at "easy" when you can have easier AND more coherent?
Besides, REST is anything like easy. Case in point, almost nobody ever correctly implemented the original REST spec -- that's why everybody calls their implementations "REST-ful", they are some loosely inspired deviations that cargo cult a lot of useless junk.
Supposedly the "real illuminated REST" (like real communism) doesn't even concern HTTP, it's a philosophy beyond web services. And yet's it's all the web related garbage part of the introductory examples that everybody follows (or tries to).
It’s an architectural style defined by Roy Fielding’s thesis (who also was the editor of HTTP/1.1 RFC). It attempted to describe the Web’s architecture in neutral terms and how it was derived by combining previous styles.
Some people took this and crafted a quasi religion out of it, but that’s partly because vendors in 2002 were all lined up trying to replace the web with a CORBA equivalent and then almost succeeded with SOAP/WS-*. People got strident to fight the dollars that were lined up. It’s easy to forget there was no powerful web/internet community with social media and blogging platforms in those days, it was all mailing lists and a couple of conferences vs. Marketing budgets, sales teams, and agenda-wielding engineers on standards bodies from Microsoft, IBM, BEA, Sun, HP, etc.
All RESTful means is that something is attempting to conform to the style. There never was a spec.
It's application for what are essentially RPC needs is which I consider cargo cult.
The HTTP REST came from people mapping HTTP verbs to RESTful actions: http://cafe.elharo.com/web/why-rest-failed/ (2006) to https://martinfowler.com/articles/richardsonMaturityModel.ht... (2010)
The people you describe used to have blogs with crappy Wordpress themes that barely got noticed by Google, now they are on a big site so get discovered I guess?
The pain you're referring to is relative to the language you used and when you touched it. SOAP is a comprehensive and we'll defined specification and when implemented properly you forget it's there because it just works.
After about 2003 major vendors had their implementations locked down pretty well. In Visual Studio you just implement a basic controller and the remainder is configuration. If you wanted to consume something from Biztalk, PeopleSoft, any Oracle Product, or any other Enterprise product you could just add a service reference to a WSDL URI and a tool would generate your interface classes and DTO classes for you in your language of choice.
In the Open Source world things were very different. Whenever I would provide a service to be consumed by a vendor, I would provide reference implementations in C#, JAVA, Python, and PHP. I would spend about 15mins on C# and JAVA, then the rest of the day fiddling with Python and to a lesser extent PHP.
PHP and Python have had SOAP libraries for a decade but they require considerably more effort to even consume SOAP. I have never tried to stand up a SOAP Service with them but I can't imagine it's any good.
Around 2012 I remember working with a partner company that was using RAILS for their platform. It was an absolute nightmare for them to integrate with our existing SOAP service layer. SOAP protocol libraries were the least of their issues. No client certificate authentication in their HTTP libraries. No serious XML support. They wrote their own implementation from scratch.
Python has decent SOAP server implementation with one-to-one request/response schema modeling https://github.com/baverman/dropthesoap
There are a lot more developers out there not working for an enterprise and not using those tools. Especially the developers doing open source work or doing small scale work.
While nowadays it's fairly easy to make a Java Spring Boot application consume and serve SOAP, with automated WSDL imports and all the WS-* specifics, this wasn't pretty much never the case with anything new and free (as in speech).
I think that's the link missing for most developers. SOAP was intended to allow machine-generated SDKs to remove all of the sharp edges of dealing with it, and in that regard it was largely successful. What brought it down was the advent of non-"enterprise" web development—development happening outside of a .Net or Java IDE that generated code for you. If you ever had to handroll a wrapper for a SOAP endpoint though, god help you. I honestly believe SOAP was the thing that made XML seem uncool by comparison to JSON and REST. JSON still doesn't solve data representation problems as well as XML, we've just learned to accept "good enough" in its stead.
I've tried suds and zeep. They both didn't really work in my specific cases. My strategy from now on is to write a bit of code in Visual C#, then analyze the xml traffic, and then generate that same XML using Python/PHP. The SOAP protocol is actually pretty simple once you know how it works.
SOAP has a lot of problems, but it's pretty amazing that you don't need a client side library to use it in Visual C#.
The REST way allowed one to get started with something small and simple that people could agree to just by talking it over together. With SOAP you had to make all those decisions up front and put it in the specification. I believe SOAP is so complex that it's an analog to CORBA/IDL.
REST is (at least initially) simpler and less specific than SOAP. That's its strength.
SOAP was intended to facilitate the same programming model but more loosely coupled. So that's not at all far off. And for what it intended to be—a specification for machine-generated bindings and SDKs—it was quite successful. It just didn't make the usability leap over to web development that happens outside an IDE.
OK, that is indeed the most usual response to "Why REST?". The main reason why people like REST is "because SOAP". It's a false dichotomy that the industry has fallen for.
Oh, yeah, and you can run the GETs directly in your browser/cURL. I like that part too, but it only gives you so much.
REST is more of a philosophy, than a standard. Hence everyone does it differently, and you have no chance to use the same library to talk REST with multiple different services (unless you make that library an overcomplicated beast).
XMLRPC? It's a universal standard, that is just a few pages long and everyone can grasp it in their lunch break. Nobody would complain that your API is not "XMLRPC enough". It works (almost) the same way everywhere. You can get the XMLRPC library that's been built in since Python 2.2 and be reasonably sure that you are going to be able to talk to a random modern XMLRPC API. You'd have other such libraries for every major language. Ditto for JSONRPC, if XML sounds too scary (though it doesn't really matter much - it's a mostly transparent implementation detail).
I'd wish people would stop bringing up SOAP as an excuse for REST. Yes, it was worse, but that does not mean that REST is particularly good.
There are HA microservice and REST model libraries/clients that do it much easier and without XML :D
You have to give it up to Colfer protobufs on zeromq and kafka :D
edit: stray click
GRPC is fun too. I miss my fiber interconnected compute though.
Furthermore, and it's been this way for as long as I can remember, too many want a tool to be the perfect fit for every problem.
That is, they pick up a screwdriver and then are shocked that it's not good for driving nails.
There is no OSFA technology.
IMHO REST is not easy to implement, it's easy to say "oh... okay I think I've got it... let me try" but it's very hard to implement RESTful APIs and the author mention a few valid pain points.
Simple use cases like: a user forgot their password, what the proper way of handling this case? A PATCH for a User based on ID? If the ID is a integer ID then you have to query user by email or username before you are able to request a new password, if the PATCH handles this case what other cases does it handle? Can a user request a new password and change their age at the same time, is this a valid case? How you structure your controller to route to these special cases, do you create a custom endpoint thus making your API less restful?
One thing I like about GraphQL is this idea of mutations, in many cases they are analogous to RPC calls, `userForgotPassword(usernameOrEmail) -> forgotPasswordResult`.
You think this guy is a hateful hipster, but most of what he says probably resonates with most software vets. To me, it's mostly against the REST zealots who demand REST is done in a very particular manner. I've seen companies with a very stable, robust RPC framework that had a small faction of REST zealots who were extremely against it because it didn't do things according to REST. It didn't matter to them how stable it was or how well it worked.
Also, REST is relatively not popular - what percentage of the world's APIs use REST do you think?
TBH, you're the one coming off like the hateful hipster to me.
I'm not part of the new world so I guess I don't feel at home there.
https://news.ycombinator.com/newsguidelines.html
I tried several times, but it seems constructive criticism or criticism isn't wanted. Proposing changing the voting system to up voting only, and create a report button. The downvoting makes a lot of bad things possible.
Several people sent me mails recently, responding that they fear they would get banned if they write as open and free as I do, and free speech isn't a thing on HN. Well, unfortunately it seems they were right.
And if you verify all the HN news that got moderated/hidden that don't suite your world view, it is appalling. (I don't know if it just the view of two moderators (dang, sctb, maybe a third) or of more people behind.)
In a newspaper I read recently that HN forum is a kind experimental model for Democracy 2.0, and featured as negative example were unpleasant comments get hell banned. Sounds more like communism of the 1970s, than what our country "is" and "needs" as model.
Anyway, I would like to see HN as news site for startups, VCs and SV. Not boring things from corporate IT and PR for them. What's the goal of HN? Cater all, or cater the startups and VCs and Ycombinator? Hint: there is already Reddit, for the rest. Please focus on the first, and move the offtopic stuff to a new "page two".
Repeatedly? I was questioning if certain accounts are corporate PR drones and downvoting bots, yes. (At least two companies employ very visible a bunch of accounts, and use them to flag/votedown articles and add troll comments to get articles hidden, while they publish "good news" in the very same moment. It's visible on the web, you are in partnership with those companies, and one can guess YC profits from the partnership). But beside that not so much. Unfortunately, two admins never found any evidence, they said, and just said shut up or we ban you. Yeah free speech isn't something on HN. News get marked as hidden every single day, that have many comments and/or high votes, and the two mods never found any evidence and always said "it's the users faults, they flagged it", yeah right, not.
Some people take religious discussions about REST to the extreme (usually about not being RESTful enough)
The same extremists probably never met real world problems or did some questionable quirk to solve them that they sell as true gospel.
In far too many RPC protocols, calling functions that operate over a network are treated like normal functions. A function call, almost by definition, fails to take into account network errors, and race conditions where multiple events overlap. Network calls are not function calls, and the fact that REST calls are relatively distinct from normal function calls is a good thing.
However, most of the Getting Started articles that you find about any publicly published REST API usually starts you off with a bunch of curl commands.
Even if the networking aspects are completely hidden from you in your application, your formative experiences with the REST API almost certainly was with the network requests.
Agree with your second point though... network requests are hard. They are not much different from real distributed programming. Making REST requests should be done with care.
There is no solution to the "A knows X, but B does not know that A knows X, or A does not know that B knows that A knows X, or B does not know that A knows that B knows that A knows X..." problem.
Other than that, I think at some level networking is nothing more than function calls that can take a long time and/or fail.
It's fine, people can understand "this function does network I/O so be careful".
Back in the day of the C64 etc, programmers had to worry about the underlying hardware as they were for the most part working with assembly.
But as increasingly abstract languages have come to be (most modern ones use virtual machines and garbage collectors), the programmer never have to consider the hardware their code has to interact with at some point. End result is all manner of bloat and memory leakage.
The article talks about how to communicate between systems. But many systems don’t need to be distributed.
If you can avoid writing a distributed system, that’s easier than even a “better REST”, if such a thing were to exist.
For example, old-style non-SPA web applications, can directly use underlying logic classes directly, can throw exceptions, need not serialize data, one connection to the DB with one transaction capable of rollback, and so on.
Or monolithic servers rather than microservices.
Sometimes you need RPC, but for those situations where you don’t, avoiding RPC completely is a significant reduction in complexity.
Much of the problem of any tech becomes that engineers/developers are supposed to make complex things simple but instead sometimes make simple things more complex because it seems smarter. Complexity is needed only enough to make it simple to interface with and consume. REST is an example of web services done right and more simple compared to SOAP which was supposed to be the Simple Object Access Protocol but they forgot the simple part and just kept adding layers.
APIs should be easy to work with and as non changing as possible in the public signatures and routes/data/configs or else versioning should come in on major changes which should be handled wisely. Sometimes that is RESTafarian or pragmatic, sometimes more HTTPRPC, sometimes that means schemas for consumption, sometimes pretty urls, sometimes ids and name blurbs, sometimes responses wrapped in app messages/wrappers, sometimes directly on HTTP(s) response bodies, and it all depends on if it is public or private and if you control both endpoints, the clients and business needs.
When you start out doing RPC you think, I don’t want to bother with schemas, I don’t want to bother with hierarchical error codes, I don’t foresee the need to set the user’s password but not retrieve it. So you don’t want to bother with a technology which makes your life more difficult, to solve problems you don’t have and cannot foresee.
So you choose something simple. But you run into all these problems anyway, because they exist, no matter if you were capable of foreseeing them or not.
But by then it’s too late. You’ve written 50 KLOC and you just have to keep going.
I believe this is why many technologies become popular which are actually too simple to handle the types of problems they try to solve.
I blogged about this concept here: https://www.databasesandlife.com/the-cycle-of-programming-la...
Only to realize later postgres offers fine locking capabilities far beyond what you've created (now that you get it).
Then you realize that all anybody is doing is creating subsets of Erlang (half serious). So why aren't we all using that?
In the grand scope, is it really a bad thing?
We end up with X ways to solve problem Y and you never know X + 1 could have some advantages. Exploration should be encouraged IMO!
Is there a superset of Common Lisp and Erlang? Such a language would be unmatched for already containing everyone's clever ideas!
http://lfe.io :)
I don't think that everything is standing still, though. Usually each successive generation has an edge on the previous one; either the previous generation was constrained by memory or CPU or bandwidth and had self-limiting architecture because of it, or the next generation needs to solve a problem involving an order of magnitude more data or compute and it needs a different approach.
But, of course, not everyone (or, realistically, not many people at all) is constrained by the thing that causes the revolution; people usually just get on the bandwagon because you must, if you don't you won't be as employable, won't be as hip, you'll find it harder to employ engineers to work on your project, etc.
"All good solutions to existing problems have been discovered. There may be new problems which need new solutions, but no one will ever improve on what we have already done. Anyone who things they can is a child playing in the dirt."
The worst force you to embrace the entire complexity before you can even hello world.
Progress is being made.
This is what I said.
One element of it is also that in many cases the path to "becoming big" starts with bootstrapping and experimental projects that you may not know if it is going to survive and exist in a few years or if you are going to throw it away in 3 months.
So in those cases you may still choose to be scrappy, knowing that it will come back to bite you, but at that stage that is thought of the success scenario and a good problem to have (if it happens at all).
This is in contrast to large serious projects for large existing companies where you can much more confidently know that X and Y are going to be required because from day 1 you know the project is not just some casual thing.
This is also why I think the software creation process and tools need to seriously think about having adjustable safety/pain knobs to allow for cheap scrappy prototyping but also allow to tighten the screws for production.
You can kind of see a glimpse of this between various programming languages, particularly in their type system. But the general concept is broader than just that.
Scrappy bootstrapping is a double-edged sword. On the one hand, it brings us great new products. On the other hand, ignoring some real-world concerns can be a major problem for users. As just one example, consider the impact for people with disabilities (e.g. blind, mobility impaired) who need to use an app that was developed with no regard for accessibility. And I've blissfully ignored other real-world concerns myself. For instance, the first desktop app that I worked on (in my 20s) had no support for HTTP proxies (as often found in corporate networks back then).
> "Any sufficiently complicated X contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Y." (where X is the new "simple" way and Y is whatever the greybeards are using.
And thus we have a constant churn of dependencies an broken APIs/ABIs...
I'd much rather use a simplistic tool while I still get away with it, risking having to switch to a more complicated tool later, than starting off with something way too complicated for what I need.
Chances are the difficulty isn't in switching from REST to SOAP, or the other way around, but in dealing with the all the assumptions that permeate those 50 KLOC. In the end it just comes down to having a clean code base that can be steered in another direction.
Note that I only mean not dealing with what cannot be easily be foreseen. Turning a blind eye to what you should know will soon be a problem, is a different story. As an example, if you ignore concurrency from the start, that will be hard to set straight later.
Even worse, you have to maintain both the old and new versions of the API code, because turning off the old API endpoint is going to take at least a year.
It's not really true that there are no standards, they defined Open API, it has a nice browser based editor to update the YAML files and it's easy to read an maintain.
All changes to the API-s are done via pull requests, so changes are reviewed.
The HTTP verb is also a non issue, there's 4... FOUR that you need to match with CRUD. Is that hard? Even if it is, read the docs.
It's like comparing a micro web framework with a full web framework.
I think it always depends what you want to do in which scale with REST. What's great for a single hobby developer would be bad for a big world wide corporation.
If you really want more rules, more restrictions and more boundaries for 100 of developers working on your project you should definitely look on something build on top of it (graphql, odata) or one of the replacement architectures like grpc if you have high demands in your infrastructure.
For me as a developer I'm always happy when things are not overcomplicated at the beginning, but some developers like more structure down the road. At the end you need to get stuff done and I think it's better to educate yourself about REST in general than some big other framework which you need to implement somehow everywhere.
So that's some common ground. It's a bad idea.
The primary problem with REST is that most people learn it by example. Then they believe it is about web services returning JSON or about pretty URLs. It is not.
If you were working in a strongly typed language with RPC calls, you would see the same problems, or symptoms thereof. For example, if you had the two RPC calls storeFoo and retrieveFoo, you'd expect them to both take Foo objects, no? Something like,
and PUT/GET in HTTP yearns for the same dichotomy.> So what do you do with the numerous read-only parameters returned by GET (creation time, last update time, server-generated token…)? You omit them and violate the PUT principles?
Yes, and just call it POST, since it's no longer symmetric and violates PUT principles. REST has nothing against POST. Again, this problem would be reflected similarly in RPC:
(or perhaps storeFoo ignores some fields on Foo, etc.)> creation time
This is a fantastic example, because I actually had this problem w/ a non-RESTful API. We took a generic sort of "create record" and recorded the current time as the "start" time. The problem was when the device lost network connectivity (which was essentially always, just a matter of "how bad is the latency): the creation of the record would lag, sometimes by hours, and the eventual "creation time" it was tagged with was wrong. We should have trusted the device, because it knew much better than the server when the actual record was created.
Now, this isn't going to be the case all the time; sometimes you literally want just the time the DB INSERT statement happened, and that's fine.
> Pick your poison, REST clearly has no clue what a read-only attribute it
POST a "create" request, GET has the newly created fields. Symmetric PUT/GET is nice, but show me where in HTTP it is recorded as an absolute.
> Meanwhile, a GET is dangerously supposed to return the password (or credit card number)
Not only does REST not dictate this, nobody in their right mind should do this. GETs just return the resource. What that resource is, what data is represented — that's up to you in HTTP just as it is in RPC.
> lots of resource parameters are deeply linked or mutually exclusive(ex. it’s either credit card OR paypal token, in a user’s billing info)
If your request looks like,
Then your RPC would look like, and you're in the same hot water, again, just with RPC. If your type system allows it, you can make them mutually exclusive there, perhaps something like, but then, that cleanly translates back into a RESTful API's information too. Now, JSON is typically used, and it doesn't really expose a real sum type, which is a shame. You can work around it w/ something like, and it works well enough. If you can't express it in the type system (in either RPC or REST) then you have to do some validation, but that's true regardless of whether RPC or REST is in use.> you’d violate specs once more: PATCH is not supposed to send a bunch of fields to be overridden
…how is that a violation of the spec?
> The PATCH method requests that a set of changes described in the request entity be applied to the reso...
Soap is just a crap by a committee of idiots.
If you like this blue is new white pattern, consider Javascript is new J2EE instead.
What developers didn't like about SOAP aren't necessarily the features, it's all the XML.
Decades of horrific developer pain disagree with you. The “tools@ all have different ideas of what is correct, good style, the right name spacing and encodings...
Feels refreshing to be called young.
Just this week I was having the pleasure of using XSD schema validation to ensure files aren't corrupted.
Do you love ASN.1 as well?
Well, REST is architecture. Protocol Buffers are (de/)serialization.
I've tried it before (& although it has the properties I like[language agnostic schema definition..]), it was finicky to get working with of one the biggest IDEs out there(IntelliJ IDEA)
Also, it doesn't support Kotlin yet.(Java interop only option)
The only place I can see Protocol Buffers being useful is inside Google..cos it was a pretty crappy dev experience.
And I would be pretty confident in saying that not many Googlers/ex-Googlers outside Google use it. Cos if they did, somebody would make the dev experience much much better.
What does that mean? REST is a style while protobufs are a serialisation format: a REST architecture can use JSON, protobufs, Thrift, whatever.
http://graphql.org/
Has the author considered something built upon Protocol Buffers, which have can have reasonable versioning semantics and is portable and supports status code canonicalization, like gRPC?
The only downside - it required a reliable and precise implementation that took a lot of efforts. I always used IIOP.NET for most of my gigs and it was excellent. I also ended up as an active IIOP.NET contributor.
CORBA ORB implementation was a fine art a few could grasp. And this was the biggest drawback - the standard was (and is) excellent, but most implementations tend to be complex and shaky.
I still actively use CORBA. The server usually offers two kind of endpoints: REST for third-party integrations (which are usually naive and simplistic), and CORBA for the system itself. I've built nice things with such architecture that involved worldwide deployments including embedded hardware. I am very proud of my involvement and the fact that I could help to improve the everyday routine for many people worldwide.
But CORBA was haunted by a key principle that limited its influence. Unlike the IP protocol stacks, which are layered from the lowest wire protocols on up to the highest layers, CORBA dictated the highest level protocols and didn't address the lower level protocols. Different CORBA implementations couldn't talk to each other; consequently, CORBA didn't work for my company because we were was trying to design a product that could work across heterogeneous networks of workstations and servers.
If the CORBA folks were so smart (and they were), how could this happen? Why didn't they design the original CORBA protocols from say UDP or TCP on up? The CORBA members were all from different companies, and all had different independent products. There was fierce competition in this space so it was impossible for the members of CORBA to agree on the low level networking protocols because doing so would harm some companies' product lines while benefiting an others.