Skip to content
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

Custom HTTP methods #321

Closed
Danack opened this issue Jun 16, 2016 · 4 comments
Closed

Custom HTTP methods #321

Danack opened this issue Jun 16, 2016 · 4 comments

Comments

@Danack
Copy link

Danack commented Jun 16, 2016

Hi there!

For an API we're building, one of the api end-points we need to expose doesn't fit well within the normal HTTP methods/verbs.

Is it possible to tell swagger-php about non-standard methods so it can generate the appropriate swagger api json for them?

I had a look but it seems that they are hard-coded here, and I can't see a way to plug any other types in.

cheers
Dan

@bfanger
Copy link
Collaborator

bfanger commented Jun 25, 2016

The swagger spec defines only has the standard verbs for a path

Too generate swagger output with custom verbs you'l need to create an annotation that extends from Path and patch Swagger.

class CustomPath extends Swagger\Annotations\Path { ... }
class CustomMethod extends Swagger\Annotations\Operation { ... }
Swagger\Annotations\Swagger::$_nested['CustomPath'] = ['paths', 'path'];

/**
 * @CustomPath(path="/some/path", @CustomMethod(description="really special"))
*/
function reallySpecial() { ... }

This might work, but it's not valid swagger output.
I would really advice against using non-standard methods, think of you api of exposing resources which you can create (POST), update (PATCH), replace(PUT) or delete(DELETE). If your building a RPC style api just use POST. If you trying to document a websocket / event-stream i'm not sure if swagger is a good fit for now.

@Danack
Copy link
Author

Danack commented Jun 25, 2016

Thanks for the answer.

I would really advice against using non-standard methods, ....If your building a RPC style api just use POST.

Just to explain the reasoning, the exact operation is a clone/copy of an existing resource......using POST for that seems misleading, as POST has it's own clear meaning. Allowing a custom* method of COPY seems to make the API a lot more intuitive:

POST /foo/123 - people would expect this to update foo with id of 123
COPY /foo/123 - people would expect this to return a new foo

The swagger spec defines only has the standard verbs for a path

Oh darn. We're actually also going to be using other tools that consume the Swagger spec JSON....they're unlikely to be happy with custom verbs.

@Danack Danack closed this as completed Jun 25, 2016
@bfanger
Copy link
Collaborator

bfanger commented Jun 26, 2016

Thanks for the explaination, I'd personally would go for POST /foo/123/clone or POST /foo/123/create-clone is this case

@Danack
Copy link
Author

Danack commented Jun 26, 2016

Yeah, I'll almost certainly do that.

I also just realised that the COPY verb actually doesn't have the correct semantics either, as for WEBDAV where it apparently comes from, you have to send an id to copy it to, and COPY is meant to be idempotent.

A CLONE method wouldn't be idempotent, and the client wouldn't know the id before the clone...so yeah, give up and use ~~~tables~~~ POST.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants