-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
REST API v3 #6
Comments
Some things missing in my proposal are:
|
Everything here seems like a solid idea to me. |
@nicatronTg What do you suggest for starting the server through REST? I cannot think of an other way besides not completely exiting TShock. |
You'd most likely need to separate the HttpServer process handling REST requests from TShock/TSApi in order to do that. |
Any updates on this? |
Rest V3 is coming with Orion at some point. With Orion we are moving to https://github.com/DeathCradle/Open-Terraria-API. OTAPI has webapi built in so we will eventually construct our REST layer on top of that. It's not going to be soon, but it will happen. |
Throwing out updates, I'll make it a point to discuss with DeathCradle where the REST API integration is with OTAPI and get this on my "to-do soon" list if it's in a working state. |
@Ijwu @DeathCradle poking you both on this issue since it hasn't been worked in ages |
I will have to have a 1 on 1 with @DeathCradle and actually figure this stuff out. If I don't get the chance to talk to him then I will look at the current OTAPI source and see if a REST framework is built out at all. I would say there hasn't been progress on this all year, it fell through the cracks as a non-essential feature. I'll personally pick up on this and see where we can go with it. |
Please document this conversation here. I don't want to have the conversation lost in Slack or something and then never documented. Otherwise, sounds good c: |
@DeathCradle Confirm for me, then, that there is currently no progress towards the REST API within Orion/TShock 5. |
@Ijwu see #33 - the progress is with a REST service, which spins up a fully managed instance of OWIN self-host with WebAPI 2 front end. It should harvest controllers within the current app domain, and should be ready for controllers to be added in other services. Alternatively, we can discuss a design where controllers are constructed dynamically by calls to a REST service method like There most definitely is progress. Thanks to @DeathCradle for all his work on it |
At least far as I'm concerned right now REST API will be fully implemented in Orion and no REST stuff will touch TShock unless it's TShock related (warps come to mind). If this isn't the intention then let me know so I can update the feature table for TShock 5. |
Agree, not currently. But TShock can feel free to yield its own endpoints to the REST service as it sees fit. Most of the REST functionality will interact directly with other services to instrument the services' operations remotely. |
Well right now things like AAA are handling what TShock was; I'd say that probably takes care of a lot of it. Things like warps and regions I could see being exposed by TShock over rest and not Orion. |
AAA's implementation (and all of the relevant parts of TShock) shall be moved into TShockv5 when they are done and someone spins up an assembly. Most of that stuff hijacked from TShock is only in Orion right now to support easy development&test methodologies, and will be moved out as we draw closer to a public release |
Cool. I'm completely confused now.
|
@tylerjwatson so is Orion going to have no services out of the box? Right now I was classifying Orion as handling core authentication + database. Is that not correct? |
@nicatronTg Orion contains service definitions, TS5 will contain concrete implementations. E.G., IUserAccountService would be in Orion, while PlainTextAccountService would be part of TShock |
So, just for my curiosity, the benefit for creating the service definitions in Orion is...? |
Orion is a mid-level wrapper for OTAPI. Orion acts a full API providing services for anything a plugin should need. Plugins request a service and it is provided to them. An english example using the aforementioned IUserAccountService: In this way any service implementations can change , but because plugins depend upon the definition, they do not need to update to conform to the implementation change. Hope that helps a bit |
TShock's REST API v2 is out for quite some time now and it would be nice to have a next version. This gives room to fix some inconsistencies, remove duplication, fix issues and add features.
For example purposes, I will use
127.0.0.1
for the host and7878
for the REST port. Also, because JSON does not officially support comments, I "faked" the comments.Consistency
Base URL
One issue we currently face is that you have to use v1 for some endpoints and for some other endpoints v2. In v3 everything should be called from http://127.0.0.1:7878/v3/.
Keys
Keys MUST be
lower_under
.Values
A value SHOULD NOT contain multiple values.
buffs
from REST v2 is a good example of how it should not be done.Dates
All dates SHOULD be available as specified in ISO 8601.
Security
GET can expose sensitive data. And besides,
Like in v1 and v2, the token should not be in the URL.
Endpoints
Tokens
Generating a token
Deprecates:
/token/create
http://127.0.0.1:7878/v3/token/generate
data:
Example response:
Validating a token
Deprecates:
/tokentest
http://127.0.0.1:7878/v3/token/validate
data:
Example response:
Server
Information
Deprecates:
/v2/status
,/v2/server/status
http://127.0.0.1:7878/v3/server/info
data:
Example response:
Executing a command
Deprecates:
/v2/server/rawcmd
,/v2/world/butcher
,/world/meteor
,/world/bloodmoon/{bool}
,/v2/players/kick
,/v2/players/kill
,/v2/players/mute
,/v2/players/unmute
,/v2/world/save
,/v2/server/broadcast
http://127.0.0.1:7878/v3/server/execute-command
data:
Example response:
Changing server password
http://127.0.0.1:7878/v3/server/update-password
data:
Example response:
Shutting the server down
Deprecates:
/v2/server/off
http://127.0.0.1:7878/v3/server/shut-down
data:
Example response:
Starting the server up
New feature
http://127.0.0.1:7878/v3/server/start-up
data:
Example response:
World
Information
Deprecates:
/world/read
,/v2/server/status
http://127.0.0.1:7878/v3/world
data:
Example response:
Auto-saving
Deprecates:
/v2/world/autosave/state/{bool}
http://127.0.0.1:7878/v3/world/auto-save
data:
Example response:
Groups
Group information
Deprecates:
/v2/groups/list
,/v2/groups/read
http://127.0.0.1:7878/v3/groups
data:
Example response:
Create group
Deprecates:
/v2/groups/create
http://127.0.0.1:7878/v3/group/create
data:
Example response:
Update group
Deprecates:
/v2/groups/update
http://127.0.0.1:7878/v3/group/update
data:
Example response:
Delete group
Deprecates:
/v2/groups/destroy
http://127.0.0.1:7878/v3/group/delete
data:
Example response:
Users
Registered users info
Relevant: Pryaxis/TShock#901
Deprecates:
/v2/users/read
http://127.0.0.1:7878/v3/users
data:
Example response:
Online info
Relevant: Pryaxis/TShock#901
Deprecates:
/v2/server/status
,/v2/users/activelist
,/v2/players/read
,/v2/players/list
http://127.0.0.1:7878/v3/online-users
data:
Example response:
Create user
Deprecates:
/v2/users/create
http://127.0.0.1:7878/v3/user/create
data:
Example response:
Update user
Deprecates:
/v2/users/update
http://127.0.0.1:7878/v3/user/update
data:
Example response:
Delete user
Deprecates:
/v2/users/destroy
http://127.0.0.1:7878/v3/user/delete
data:
Example response:
Bans
Deprecates:
/v2/players/ban
REST API v1 & v2
v1 is out for a very long time. I propose to remove the support to get rid of legacy code. I also propose to deprecate v2 and remove it in August 2018.
Feel free to comment on this. I might have missed something or made some mistakes along the way.
@WhiTexz If v3 is already out, then you can obviously name it v4. I am not aware of v3.
The text was updated successfully, but these errors were encountered: