Show HN: RESTful Doom – HTTP+JSON API inside Doom
21–30 of 31 posts
Re: Show HN: RESTful Doom – HTTP+JSON API inside Doom
#22Awesome work, btw!
Re: Show HN: RESTful Doom – HTTP+JSON API inside Doom
#23Re: Show HN: RESTful Doom – HTTP+JSON API inside Doom
#24i think this could open up possibilities with live stats if each player runs their own server and the results are combined on into a seperate website? otherwise it could be used to create new game modes or a scoring system?
Re: Show HN: RESTful Doom – HTTP+JSON API inside Doom
#25Well now I'm screwed at work tomorrow, I want to tie in so much of our logging into this some how like psdoom. Q: Are the files done processing ? Me: I don't know check if the door is open in doom.
Re: Show HN: RESTful Doom – HTTP+JSON API inside Doom
#26That's pretty cool! Well done. Now I'm wondering whether the game clock could be suspended unless ticks were sent via API, to turn it into a turn-based game to be played only via API calls...
Sounds like an API version of Superhot.
Re: Show HN: RESTful Doom – HTTP+JSON API inside Doom
#27 POST /api/player/actions
Content-Type: application/json
{ "type": "shoot" }
How do I know what "type" of action is available to me? It isn't documented. Why should I need to know or try to look it up in the documentation in the first place, anyway? The server should just tell me what I can do, and then I act on it! Why should I need to know all these special URLs, except a single central entry point (a.k.a. bookmark)? The server should just tell me from each resource where I can go to! A more useful attempt: GET /
Content-Type: text/html
The shotgun is equipped.
There is a green armor ahead.
You see a baron of hell attacking
an imp.
There is a yellow-framed door,
attempt to
it.
,
…
(HTML used for ease of illustration on HN, alas JSON proper - being a dumb serialisation format - it deficient of hyperlinks or hypermedia controls, but there are extensions for it. This audience is less likely to be familiar with them.)It really bothers me that programmers call things REST, and when you look at it it isn't REST at all because they don't know the first thing about it.
Re: Show HN: RESTful Doom – HTTP+JSON API inside Doom
#28This isn't REST, there are no hyperlinks and no hypermedia controls. It is designed pretty wrong. Just look at this brittle coupling! POST /api/player/actions Content-Type: application/json { "type": "shoot" } How do I know what "type" of action is available to me? It isn't documented. Why should I need to know or try to look it up in the documentation in the first place, anyway? The server should just tell me what I…
Re: Show HN: RESTful Doom – HTTP+JSON API inside Doom
#29This isn't REST, there are no hyperlinks and no hypermedia controls. It is designed pretty wrong. Just look at this brittle coupling! POST /api/player/actions Content-Type: application/json { "type": "shoot" } How do I know what "type" of action is available to me? It isn't documented. Why should I need to know or try to look it up in the documentation in the first place, anyway? The server should just tell me what I…
Is there /db/restEndpoints and /rpc/nonRESTfulEndpoints?
Re: Show HN: RESTful Doom – HTTP+JSON API inside Doom
#30This isn't REST, there are no hyperlinks and no hypermedia controls. It is designed pretty wrong. Just look at this brittle coupling! POST /api/player/actions Content-Type: application/json { "type": "shoot" } How do I know what "type" of action is available to me? It isn't documented. Why should I need to know or try to look it up in the documentation in the first place, anyway? The server should just tell me what I…
In a traditional REST API, where do non-RESTful things (like other API calls, or "business logic") tend to go? Is there /db/restEndpoints and /rpc/nonRESTfulEndpoints?
Other API calls depend on the purpose. If its part of the business logic, it's probably back end and hidden as described above.
If the other API call simply powers the UI, you might keep it in the client. One example is autocomple for facebook friends. The client can call facebook for a list, let the user select their friend, and then send that friends info to your API.
With that said, I'm not sure how either of those are "non-RESTful" so maybe I missed the point of the question?