REST Anti-patterns • Hacker News Board

Re: REST Anti-patterns

#111

Post by BerislavLopac » Mon, Sep 12, 2016, 7:36 PM UTC

PaulHoule wrote: post #24

This misses the elephant in the room. The REST-inspired API that requires 10,000 API calls to do something that could be done in 1. This is a disaster from a simple performance perspective. There is no simple way to build transactions on top of REST so if you need to do something that involves updating more than one data record you really are best off updating them all in one API call. When you are writing a web fron…

This issue is greatly addressed with CQRS. http://martinfowler.com/bliki/CQRS.html

Re: REST Anti-patterns

#112

Post by whamlastxmas » Mon, Sep 12, 2016, 8:11 PM UTC

Disappointing to see so much downvoting in a thread when people are just giving their opinions. Seems like a lot of downvote misuse on HN recently.

Re: REST Anti-patterns

#114

Post by recursive » Mon, Sep 12, 2016, 8:29 PM UTC

EugeneOZ wrote: post #48

recursive wrote: post #39

Earlier quoted context omitted.

URLs should... well... locate a resource. The resource is an account.

Only when it's GET request. This request will not return you any resource information, with id if account or without.

In your mind, what does URL stand for? It's an acronym.

Re: REST Anti-patterns

#115

Post by rahkiin » Mon, Sep 12, 2016, 9:13 PM UTC

jackcosgrove wrote: post #36

No mention of the biggest single problem with REST as it's practiced: POST /login. You should use POST /session instead.

What if i use JWT and thus have no concept of 'session' resources? You would actually create a token using username and password.

Re: REST Anti-patterns

#116

Post by gtramont » Mon, Sep 12, 2016, 11:20 PM UTC

amk_ wrote: post #49

fzilla wrote: post #34

Earlier 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?

This doesn't really matter. What you'll end up exposing via your API is your use case! Does your system allow for an account to be closed? Awesome! So let the client know how to do it.

If you're speaking HTML it can be as simple as:

  
    Close Account

Or even:

  
    
    Close Account

If you're speaking Siren (https://github.com/kevinswiber/siren):

  {
    "actions": [
      {
        "title": "Close Account",
        "method": "POST",
        "href": "/close-account",
        "type": "application/x-www-form-urlencoded",
        "fields": [
          { "name": "acc_number", "type": "hidden", "value": "12345" }
        ]
      }
    ]
  }

Re: REST Anti-patterns

#117

Post by velox_io » Tue, Sep 13, 2016, 12:12 AM UTC

Question 1#: Is there a reason PATCH is used (or even needed?), instead of PUT to update records? (Create, Read, Update & Delete => POST, GET, PUT & DELETE) seem like a natural fit, why complicate things?

Question 2#: What is the consensus around custom verbs? While I've never gone down this route, a few times I have been tempted.

Re: REST Anti-patterns

#118

Post by jackcosgrove » Tue, Sep 13, 2016, 12:30 AM UTC

rahkiin wrote: post #115

jackcosgrove wrote: post #36

No mention of the biggest single problem with REST as it's practiced: POST /login. You should use POST /session instead.

What if i use JWT and thus have no concept of 'session' resources? You would actually create a token using username and password.

My critique with POST /login is that it's a verb, not a noun. Whether the session is stored on the server or the client is the same regardless of the verbiage. In both cases a client-side session is a bit of semantic abuse but HTTP does not have verbs for creating resources on the client.

I think a JWT token represents a session, since it can expire and be disposed when logging out.

Re: REST Anti-patterns

#119

Post by sopooneo » Tue, Sep 13, 2016, 2:14 AM UTC

dragonwriter wrote: post #78

caseysoftware wrote: post #25

Earlier quoted context omitted.

This depends on your data model. If "status" is just a property on the accounts resource and doesn't have further meaning, I would tend to agree with you. If "close" is an action or activity that acts upon an accounts resource, then his approach makes sense. Since the context is an account that we "need to close," I would assume the author is talking about something more complex than a database field. It's probably a…

> If "close" is an action or activity that acts upon an accounts resource, then his approach makes sense. Right. Particularly, if a closure request is a thing that has its own status, identity, and associated data elements, which one might wish to examine and interact with (and, while its possible that such interaction might not be possible for external users with privileges only on their own accounts, it might well…

Certainly, though I am skeptical of that theory being true in the author's actual case. Because if it was, I would think the plurality in the URI would be consistent, and instead of

POST /accounts/4402278/close

You would have something like

POST /accounts/4402278/closures

Re: REST Anti-patterns

#120

Post by bschwindHN » Tue, Sep 13, 2016, 2:18 AM UTC

jackcosgrove wrote: post #36

No mention of the biggest single problem with REST as it's practiced: POST /login. You should use POST /session instead.

It's all made up words anyway, who really cares?