There are two ways of registering Sling Servlet as per the documentation
First is @SlingServlet
@SlingServlet(
resourceTypes = "sling/servlet/default",
selectors = "hello",
extensions = "html",
methods = "GET")
public class MyServlet extends SlingSafeMethodsServlet {
@Override
protected void doGet(SlingHttpServletRequest request, SlingHttpServletResponse response) throws ServletException, IOException {
...
}
}
Second using @Properties
@Component(metatype = true)
@Service(Servlet.class)
@Properties({
@Property(name = "sling.servlet.resourceTypes", value = "sling/servlet/default"),
@Property(name = "sling.servlet.selectors", value = "hello"),
@Property(name = "sling.servlet.extensions", value = "html"),
@Property(name = "sling.servlet.methods", value = "GET")
})
public class MyServlet extends SlingSafeMethodsServlet {
@Override
protected void doGet(SlingHttpServletRequest request, SlingHttpServletResponse response) throws ServletException, IOException {
...
}
}
Documentation doesn't lists any advantages of specific approach over other. One of my team member asked about this. One thing I could think of is @Properties allow us to give configurable properties, which can be changed from OSGi console (http://localhost:4502/system/console/components, assuming CQ is running locally on port 4502). Is there a difference or advantage of using specific approach?
@SlingServlet reduces the boilerplate required to create a servlet. Some of the properties you've listed like methods = "GET" are already set so by default, so you don't need to reconfigure it. All together, it makes the annotation much more concise.
Internally, just as all SCR annotations, the annotation is translated into the XML file so you won't be able to distinguish how the servlet was implemented just by looking on the instance with code deployed.
Nothing limits you in adding an additional @Property definitions if you want to specify a vendor or service description. Mind, the latter one is actually available in the @SlingServlet annotation so again - you'd straightaway benefit from using it!
I also recommend you reading a great presentation of my collegue who described some of the AEM development best practices (including your case of @SlingServlet). You can find it here