Today's workaround for supporting actions about katharsis-framework

[masterspambot]

The thing that you call actions are actually a custom POST transformations that exposed as endpoints for brevity.

[masterspambot]

From @weaselmetal on May 24, 2016 11:5

Meaning one would have to create a Promotion class and implement a ResourceRepository for it? Or are custom POST transformations possible in another way in katharsis?

[masterspambot]

From @Ramblurr on May 24, 2016 12:15

Thanks for the reply @masterspambot, so using the correct terminology, what's the recommended way of exposing custom transformations via POST endpoints with Katharsis?

[masterspambot]

It's more general rule of exposing methods via REST interface then just Katharsis way. If you are making any specific resource transformation that is commonly used in system - make it custom url POST call.

So as was given example in initial post you can expose promotion as custom resource method to more clearly expose the action you are making:
POST /api/employee/:id/promote
.

[masterspambot]

From @Ramblurr on May 24, 2016 15:6

Great, this is what I would expect. But how do we make this work with Katharsis? Katharsis doesn't seem to have a way to register these custom endpoints as you have suggested. We must have to use Jersey directly?

Assume: POST /api/employee/:id/promoteis the custom transform endpoint, where GET /api/employee/:id is a Katharsis handled endpoint.

• How do we register the Jersey filter so it doesn't collide with Katharsis?
  • Are there any examples of this?
• How do we return JSON API from such a custom endpoint? Can we use the Katharsis serializers from a custom jersey resource/endpoint?

[masterspambot]

From @meshuga on May 24, 2016 15:52

It's possible to expose POST /api/employee/:id/promote endpoint by defining a to-one relationship to Employee resource class and creating a RelationshipRepository which will contain just one method that implements your custom method. Sounds strange, but the actual implementation looks interesting. I should add a sample to katharsis-examples.

[masterspambot]

I think we should improve this @meshuga to make make exposing custom
methods more easily.

wt., 24.05.2016 o 17:52 użytkownik Patryk Orwat [email protected]
napisał:

It's possible to expose POST /api/employee/:id/promote endpoint by
defining a to-one relationship to Employee resource class and creating a
RelationshipRepository which will contain just one method that implements
your custom method. Sounds strange, but the actual implementation looks
interesting. I should add a sample to katharsis-examples.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/katharsis-project/katharsis-core/issues/327#issuecomment-221316404

[masterspambot]

From @Ramblurr on May 24, 2016 17:18

@meshuga I understand now. I never thought of having a Resource class that did not have any ResourceRepository, but only RelationshipRepository with other resources. An example would be pretty cool, but I think I understand more or less now.

[masterspambot]

How about introducing annotation @jsonApiAction? @meshuga? @ieugen?

[masterspambot]

From @weaselmetal on May 31, 2016 13:43

If the suggestion of @JsonApiAction is meant to decorate a method that should handle a certain request, that would be an awesome extension. Modeling a to-one relation is fair workaround, which is especially okay with our project, where we have a layer of POJOs sitting between the API endpoints and the actual entities that we store in the database.
But if POST /api/employee/:id/promote in fact only changes the role and salary of of the employee (for example), I would not want to design my real domain model in such a way:

class Employee
{
  @JsonApiToOne
  Promotion promote;
}

Of course if Promotion is a real entity that is also persisted, such a relation is fine, otherwise it would pollute my model. Imagine multiple actions on one object.

Whereas, something like that would be a great thing to have (IMHO)

@JsonApiResourceRepository(Employee.class)
public class EmployeeRepository
{
  @JsonApiFindOne
  public Employee findOne(Long id, QueryParams params)
  {
    // ...
  }

  @JsonApiAction(POST, "/{id}/promote")
  public void promoteEmployee(@PathParam("id") Long id, QueryParams params, JsonNode payload)
  {
    Employee employee = employeeService.findOne(id);
    employeeService.promote(employee, payload.get("newPosition")); // may throw some exception
  }

  @JsonApiAction(GET, "/countAll")
  public ObjectNode countEmployees(QueryParams params)
  {
     return new ObjectNode().addField("count", employeeService.countAll());
  }
}

In that case, methods annotated with @JsonApiAction should be able to return non-@JsonApiResource objects I guess.

[masterspambot]

From @Ramblurr on July 15, 2016 9:38

@meshuga @masterspambot Any word on the status of this enhancement? Even a timeline for implementation would be great.

To summarize the important features are

• Some way of specifying an HTTP handler for non jsonapi CRUD operations
  • Possibly via @JsonApiAction as @weaselmetal suggested above
• Option to return serialized JSON
• Option to return non-JSON (e.g., a file via a stream)

On our end we would be willing to contribute this feature with our dev resources, if we can get some commitment and agreement on the design implementation.

[masterspambot]

From @ieugen on July 16, 2016 13:35

Hi,

We also need support for actions in JSON-API in our production app. IMO it is not very easy to support in with the current code base. That is one of the reasons I started working on https://github.com/katharsis-project/katharsis-core/pull/326 . One of the goals is to allow hooks to call and support actions.

I have similar ideas to what you have detailed in your comments. I was thinking to make the calls like
/api/employee/:id/actions/promote (similar to how relationships are referenced). The only reason is to make parsing easy, and not look for a field with the same name. But since actions are usually verbs, the chances of a field with the same name should be small.

@Ramblurr : I believe that in a week or two the PR will be ready for beta testing. So most of the features will work. The struggle so far is to keep the API the same to provide users a simple migration path from 2.4 to 3. Could I count on you for some help when the time comes? I will be available for chat to help you with the migration if necessary.

[masterspambot]

@ieugen Is true here. We have to set up a ground in order to consume and expose actions easily, so I am placing this issue in Backlog to be implemented when possible.

[Ramblurr]

@ieugen We can definitely help with beta testing.

[NotGrm]

Hi,

Any updates concerning this feature ?

Do you need help with beta-testing and/or development ?

[meshuga]

Hi, there's no progress in this subject. If you or your team has spare time it would be great to do some development of what @weaselmetal mentioned about the annotations and @ieugen about the path structure.

[NotGrm]

Thanks for the feedback. I will take a look to help in development but I can't ensure of a result due to my limited spare time and my limited java skills 😢

[dkushner]

Perhaps I am a bit confused about the role of the Katharsis project, but aren't these operations a bit beyond the scope of the JSON-API specification? Surely Katharsis does not actively interfere with you building a specialized action route and controller that is congruent with the JSON-API defined route but handles your specific behaviour?

[remmeier]

is there an update in this area? a prototype or something?

[remmeier]

I think here nothing new needs to be designed/implemented. JSON API is great for resources. And Katharsis is an implementation for that. To write generic actions there are already implementations like JAXRS and Vertx. Desigining something similar in Katharsis would take a huge amount of time. Instead, Katharsis should just be extended to play nice with those implementation. Like allowing JAXRS annotated methods in a resource repository (if jaxrs setup is used). And that would actually be pretty easy to achieve.

@JsonApiAction would still be a good thing as mentioned above to setup proper linking from resources to actions. This way the approach would also closely match what has been discused here before.