
No further development on Simple.Web - numo16
http://blog.markrendle.net/2014/07/25/no-further-development-on-simple-web/
======
evv
> When I create an API, web or otherwise, it is rarely of the type popularised
> by Ruby on Rails, ASP.NET MVC and most other MVC frameworks. These tend to
> think of an API as simple resources with HTTP methods – two GETs, a POST, a
> PUT and a DELETE. That’s not an API. That’s just a basic Data Access Layer
> over HTTP. Sure, I’ve written code where that is a valid pattern for certain
> resources, but it’s not an API. An API provides high-level commands and
> operations, such as “activate this user” or “complete this order”.

I disagree. A resource-centric "restful" http interface is most certianaly an
API. These high level commands can be easily expressed with a PUT request on
the user to activate, or a PUT on the order resource to complete it.

In theory, we could always go back to the days of JSON RPC where every request
is a POST to /api.json with { action: 'getUser', userId: 123 }. IMO, the
rails-esque API conventions are a significant improvement.

Is there an alternative routing technique which you prefer? I wouldn't know,
but maybe the .NET ecosystem has a library for creating APIs with proper
conventions for classes, objects, and methods.

~~~
delluminatus
Yeah, I'm not sure how using a route table precludes having "an API". You can
still have controllers and actions with fairly arbitrary names. More to the
point, there is no reason why a DAL-style API can't do things like "activate
this user". Just let them CREATE new UserActivation objects.

~~~
mmatants
I think "activateUser" seems more semantic than "UserActivation/create" \-
that's just Kingdom of Nouns again.

~~~
ollysb
That seems incredibly easy to represent as a patch

    
    
        patch /users/1 { active: true }
    

or as patch for json

    
    
        patch /users/1 { "replace": "/active", "value": true  }

------
wrs
It's funny how someone who doesn't want to "think of an API as simple
resources with HTTP methods" can take inspiration from HATEOAS, where that's
pretty much the whole point.

