- REST Anti-Patterns [0]
- API Anti-Patterns: How to Avoid Common REST Mistakes [1]
[0] https://www.infoq.com/articles/rest-anti-patterns
[1] http://www.programmableweb.com/news/api-anti-patterns-how-to...
REST Anti-patterns
81–90 of 133 posts
Re: REST Anti-patterns
#82What about error representation? Most of the time I find that actually representing errors is the hard part of creating a REST api. You usually want some representation of each field, plus maybe a generic one. I always have troubles with this. Is there a standard or a proper way to define/do this? I would be very interested.
There's an RFC for that! https://tools.ietf.org/html/rfc7807
Re: REST Anti-patterns
#83Earlier quoted context omitted.
REST is just a representation of the underlying data. What does it matter if "status" is a database field or not? More specifically, it shouldn't have to matter to consumers. Because of the way REST and HTTP work, clients intuitively understand retrieving and modifying resources (via GET, POST, PUT, PATCH and DELETE). But they don't understand interacting with special-purpose endpoints (POST always implies "make a ne…
What if 'status' isn't a column in the account database? What if closed_accounts is a join table or something else? Then wouldn't adding a /close route be hiding idiosyncrasies in your data model, not the other way around? It seems like we spend a lot of time designing object relations that map a domain, but maybe not so much mapping domain-specific actions. Or would you consider all of the above bad practice?
> What if 'status' isn't a column in the account database? What if closed_accounts is a join table or something else? Then wouldn't adding a /close route be hiding idiosyncrasies in your data model, not the other way around?
So what? REST is an API [0]. It's the public interface you expose. What you do behind the scene in your data model is, or should be, irrelevant to the API. Sometimes you'll map your data model practically one-to-one to the REST API, but there are times when I do significant logic in controllers before mapping the result of that logic to a resource. As long as the API is resource oriented and follows good REST practices, it's all good.
0. OK, REST is one way to expose an API, since the wording I used is not amenable to some people.
Re: REST Anti-patterns
#84> POST /accounts/4402278/close
I'm not really sold on this one since "close" is not a resource. I think I would do:
PATCH /accounts/4402278
Re: REST Anti-patterns
#85Earlier quoted context omitted.
What if 'status' isn't a column in the account database? What if closed_accounts is a join table or something else? Then wouldn't adding a /close route be hiding idiosyncrasies in your data model, not the other way around? It seems like we spend a lot of time designing object relations that map a domain, but maybe not so much mapping domain-specific actions. Or would you consider all of the above bad practice?
> What if 'status' isn't a column in the account database? What if closed_accounts is a join table or something else? Then wouldn't adding a /close route be hiding idiosyncrasies in your data model, not the other way around? So what? REST is an API [0]. It's the public interface you expose. What you do behind the scene in your data model is, or should be, irrelevant to the API. Sometimes you'll map your data model pr…
> REST is an API.
No, REST is an architectural style.
Re: REST Anti-patterns
#86I'm currently working on a Database Proxy API Project I cooked up (essentially creating a way I so we could query our different MySQL and Oracle databases using a RESTful API) and it makes sense for me (from the RESTful perspective) to use a GET request to send the query.
However, I know that the request body (a JSON string or a JSON array that could contain one or more queries, along with one or more different decryption keys allowing the server-side to retrieve the connection details that are encrypted on the server) could be quite long (we have some massive SQL queries that get used elsewhere and could potentially be used with this new API once it's available) and I also didn't like the idea of some of the more sensitive information being in the URL, so I decided to implement it as a POST request instead of a GET.
It feels wrong (again from the RESTful perspective since I'd like my API to be fully RESTful) but from a user point of view I know I'm making the right decision.
If anybody has better ideas though, please let me know!
Re: REST Anti-patterns
#87"Correct POST /accounts/4402278/close" bullshit. POST should not contain all details in URL. POST can have body and each query should not be unique. Stopped reading after that.
Yeah, just
PATCH /accounts/4402278
with parameter ACTIVE: 0
Re: REST Anti-patterns
#88Earlier quoted context omitted.
> What if 'status' isn't a column in the account database? What if closed_accounts is a join table or something else? Then wouldn't adding a /close route be hiding idiosyncrasies in your data model, not the other way around? So what? REST is an API [0]. It's the public interface you expose. What you do behind the scene in your data model is, or should be, irrelevant to the API. Sometimes you'll map your data model pr…
> REST is an API. No, REST is an architectural style.
> No, REST is an architectural style.
For APIs. But yes, we can argue semantics now. My point is, REST is a way to expose an API.
Re: REST Anti-patterns
#89Earlier quoted context omitted.
Your PATCH example makes sense, so I should do something like (depending on your opinions of how to do PATCH requests): PATCH /users/123 [{ "op": "replace", "path": "/accounts/12345/status", "value": "closed" }] I personally think that's less readable than the original, but I agree that it seems to more closely fit the REST standard. With the deposit, I don't really understand what's changed here from the original. T…
I would simply PATCH { "status" : "closed" }, as that's how PATCH works in rails. Regarding the deposits, the difference is that 'deposits' is a collection of deposit resources vs 'deposit' as a verb. I think in this case it makes a lot of sense to do it that way, as you can then GET /account/12345/deposits and see all the deposits ever made.
OK, so the original one used a verb at the end of the URL, whereas it should have used a noun. In practice, this wil often means that the URL is almost identical - here for example, it will be:
POST /accounts/12345/deposits
POST /accounts/12345/deposit
Even then, from experience, you end up with some horrible URLs just so it's RESTful. While I try to follow REST, I balance it against making the API readable by human beings.
Re: REST Anti-patterns
#90Earlier quoted context omitted.
This type of approach can be great. It is parallel to the idea to the "business is an exchange of documents", and the documents represent "transactions" in the sense of "an invoice", "a packing slip", "a deposit slip", "an order", etc.
> "business is an exchange of documents" Did you just make up this phrase? It's really good!
You would probably like reading [1] by Dan North.