Senior software developer at Amazon Web Services. I work on the AWS Serverless Application Repository and AWS SAM. I’m passionate about writing quality software and teaching others how to do the same.
Location
Seattle, WA
Education
BS Computer Engineering, Minors: CS and Math
Work
Sr. Software Development Engineer at Amazon Web Services
REST APIs never work well for these kind of things.
Disagree. I've seen it work well many times.
PS: That last api should be
GET /accounts/?customerId=<customerId>
Totally see where you're coming from, and I started out following this pattern as well. However, I've found this to be an antipattern in practice. The more queries you have to support, the hairier your query params become. Your API starts to become really complex where one query requires params A, B, and C to be set, another requires A and C to be set, another requires B xor C to be set, etc. I prefer to make each supported query explicit by separating them into a separate URI. This might also have to do with the fact that I'm implementing this API as a distributed system, rather than a monolithic service attached to an RDBMS. A lot of these nuances are less important with a simpler stack.
We can agree to disagree on whether this is "pure REST" or what Roy Fielding originally intended. I prefer applying well-reasoned pragmatism as opposed to trying to adhere to a spec, just because it's the spec.
I'm not saying that you haven't seen many successful APIs or even that the one presented in this article won't be successful. All I'm saying is that I don't think it is the way REST APIs are supposed to be done.
This really is the biggest issue with so called REST APIs. The fact that no two developers quite agree on how they should be implemented makes the term REST rather useless. If you called it 'JSON over HTTP' it would tell me more.
In 20 years developing web systems, I've yet to see two REST APIs with a consistent usage pattern. Telling me it is a REST API gives me no information about how to use it at all, which means I always have to create a client library pretty much from scratch each time.
I don't think the term is useless at all. It is very well defined. It annoys me as well that many people mean many different things when using that term. It should just be used less often. Other things are simply not REST. Doesn't mean they are bad, but they are something else.
(I do wish Fielding's work would contain more practical examples, as that would help in understanding. But hey, it's a thesis that describes an architecture style on a very abstract level.)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Disagree. I've seen it work well many times.
Totally see where you're coming from, and I started out following this pattern as well. However, I've found this to be an antipattern in practice. The more queries you have to support, the hairier your query params become. Your API starts to become really complex where one query requires params A, B, and C to be set, another requires A and C to be set, another requires B xor C to be set, etc. I prefer to make each supported query explicit by separating them into a separate URI. This might also have to do with the fact that I'm implementing this API as a distributed system, rather than a monolithic service attached to an RDBMS. A lot of these nuances are less important with a simpler stack.
We can agree to disagree on whether this is "pure REST" or what Roy Fielding originally intended. I prefer applying well-reasoned pragmatism as opposed to trying to adhere to a spec, just because it's the spec.
I'm not saying that you haven't seen many successful APIs or even that the one presented in this article won't be successful. All I'm saying is that I don't think it is the way REST APIs are supposed to be done.
This really is the biggest issue with so called REST APIs. The fact that no two developers quite agree on how they should be implemented makes the term REST rather useless. If you called it 'JSON over HTTP' it would tell me more.
In 20 years developing web systems, I've yet to see two REST APIs with a consistent usage pattern. Telling me it is a REST API gives me no information about how to use it at all, which means I always have to create a client library pretty much from scratch each time.
I don't think the term is useless at all. It is very well defined. It annoys me as well that many people mean many different things when using that term. It should just be used less often. Other things are simply not REST. Doesn't mean they are bad, but they are something else.
(I do wish Fielding's work would contain more practical examples, as that would help in understanding. But hey, it's a thesis that describes an architecture style on a very abstract level.)