This highly depends on what you need.
General answer on the question
- The Rewrite API basically does all the URl rewrite stuff.
- The Shortcode API is meant to be an easy to use extension approach for people who want to extend their posts/content with the text/html editor. As an alternative, you also/extend use the quicktag buttons in TinyMCE to insert the shortcode (layer above shortcode-abstraction-layer).
- The Widget API is normally used to build small plugins that go into
dynamic_sidebar()s in theme templates, that offer such possibility.
- The Actions/Filter API (actions are low level filters) allows you to insert or modify any stuff in core/themes/plugins/widgets/muplugins/dropins, that offer
apply_filter( 'name', $args_1, $args_etc )-filters. You can use them with
add_action( 'name', 'callback_function_name' ); (class method approach:
add_action( 'name', array( $this, 'callback_method_name' ) );).
So you can use everything as you want, but you should try to make it as easy for the user as possible. Offering template tags generally isn't a good idea. It's better to hook your main function into a hook, that the user has to add to his template:
do_action( 'plugin_special_hook' );. This way you avoid errors and warnings/notices in case your plugin isn't activated.
If you use Widgets, you have an UI that the user can use to adjust possible options.
If you use Shortcodes or TinyMCE buttons, then you got some other possibility to adjust the output.
If you got filters or hooks, then the output is generated without users involved. Or you got a Settings API admin page, where the user can adjust the output.
The rewrite API got nothing to do with above mentioned - it's not about output, it's about routing requests.
Names are just for organization ... and hooks
MU-Plugins come right after DropIns in load order and have access to the earliest hook
muplugins_loaded. Then you got plugins with the
plugins_loaded hook. Then there's the
after_setup_theme hook for plugins. Then all the rest follows with
Normally the rule of thumb is to drop everything that's not UI, into a plugin - if it has options, use a normal plugin, else use a mu-plugin. The rest goes into a theme. Or a child-theme (overriding of parent themes files possible, without loosing changes on updates of parent theme).
Replace Core parts
If you need to modify a pluggable.php function, you go with a DropIn. Hint: Don't override pluggables, as this is normally too error prone.
APIs whereever you look
There're as well some others APIs, as for e.g. the WP HTTP API, and others. Make sure, that you use them, as else the sky would fall on your head (sooner or later).