4 ms·

No further development on Simple.Web

20 points by numo16 12y ago

evv 12y ago
> 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 12y ago
  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 12y ago
    I think "activateUser" seems more semantic than "UserActivation/create" - that's just Kingdom of Nouns again.
    - ollysb 12y ago
      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 12y ago
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.

20 points by numo16 12y ago

evv 12y ago

> 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 12y ago
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 12y ago
  I think "activateUser" seems more semantic than "UserActivation/create" - that's just Kingdom of Nouns again.
  - ollysb 12y ago
    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 12y ago

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.