REST API v3 about orion-core HOT 23 OPEN

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:

from orion-core.

Some things missing in my proposal are:

• Request methods (GET/POST/HEAD/PUT/...)
• How to start the server (back-end)
• How to authenticate securely (back-end)
• Some response statuses should be more specific than 200 OK
• Some response messages should be added/improved
• Inventory: extra accessory slot

from orion-core.

Everything here seems like a solid idea to me.

from orion-core.

@nicatronTg What do you suggest for starting the server through REST? I cannot think of an other way besides not completely exiting TShock.

from orion-core.

You'd most likely need to separate the HttpServer process handling REST requests from TShock/TSApi in order to do that.

from orion-core.

With the move to v3 we should switch to OWIN and Katana as our server.

Edit: Wrong button, sorry folks.

from orion-core.

Any updates on this?

from orion-core.

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.

from orion-core.

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.

from orion-core.

@Ijwu @DeathCradle poking you both on this issue since it hasn't been worked in ages

from orion-core.

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.

from orion-core.

@Ijwu The REST framework is now done in Orion as OTAPI v2 is now purely a low level Terraria API.
The above controllers are still to be done though, in TS5 or Orion.

from orion-core.

@DeathCradle Confirm for me, then, that there is currently no progress towards the REST API within Orion/TShock 5.

from orion-core.

@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 AddEndpoint<>.

There most definitely is progress. Thanks to @DeathCradle for all his work on it

from orion-core.

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.

from orion-core.

TShock unless it's TShock related

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.

from orion-core.

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.

from orion-core.

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

from orion-core.

Cool.

I'm completely confused now.
On Tue, Oct 11, 2016 at 5:46 PM Tyler Watson [email protected]
wrote:

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

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#6 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAggp7UAfuHKk1uNRqFI2t3AiRA48HmJks5qzB_UgaJpZM4FryGK
.

from orion-core.

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

from orion-core.

@nicatronTg Orion contains service definitions, TS5 will contain concrete implementations.

E.G., IUserAccountService would be in Orion, while PlainTextAccountService would be part of TShock

from orion-core.

So, just for my curiosity, the benefit for creating the service definitions in Orion is...?

from orion-core.

Orion is a mid-level wrapper for OTAPI.
Instead of the TShock 4 architecture where plugins must depend on both TShock and TSAPI (and TShock ends up fulfilling an API role), plugins should only need to have a dependency on Orion (and any plugins they may depend upon).

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:
Plugin P wants to get a user's account, so it asks to be provided with an IUserAccountService.
Plugin TShock has registered an IUserAccountService called PlainTextAccountService with Orion.
This service is provided in its abstract form of IUserAccountService to plugin P.
P does not need to know anything about the concrete implementation provided by PlainTextAccountService.

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

from orion-core.